[improvement](ci) Refine Codex review goal completion prompt

[zclllyybb]

What problem does this PR solve?

Problem Summary: I modified the codex to support the codex exec --goal mode. The Codex review workflow now enters goal mode through the runner's --goal invocation, so the review instructions should describe the completion criteria and convergence process instead of telling the model to create the goal itself.

see modification in https://github.com/zclllyybb/codex/tree/codex-exec-goal

Verification:

• Before:
  [feature](eager-agg) Bilateral push-down for eager aggregation #63690 got 1 comment when /review

• Now:
  [test](ci) Fresh Codex review prompt validation zclllyybb/doris#49 replicated the same PR, receiving 8 comments in a single /review

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[zclllyybb]

run buildall

[zclllyybb]

/review

[github-actions]

Automated review completed. I found two blocking issues: the workflow installs and runs an unpinned executable fetched from mutable OSS storage in a privileged CI context, and the generic code-review skill now mandates subagent/GitHub-review side effects for all review uses instead of scoping them to goal-mode GitHub reviews where those tools and permissions are available.

Critical checkpoint conclusions:

• Goal/test coverage: the PR targets Codex goal-mode review orchestration; the workflow changes implement that path, but the binary provenance and generic skill scoping issues are not covered by an enforceable validation.
• Scope/focus: the change is mostly focused on the review runner and review skill, but the skill change broadens behavior beyond this runner.
• Concurrency/lifecycle/config/compatibility: no Doris runtime concurrency, lifecycle, config, storage format, transaction, FE-BE protocol, or data-write path changes were found.
• Parallel paths: workflow_call and workflow_dispatch share the changed runner path; ordinary/local code-review skill uses are the problematic parallel path.
• Tests/results: no test result files are involved; I validated YAML parsing and diff whitespace locally, but did not run the workflow.
• Observability/performance: not applicable beyond the existing workflow logging and Litefuse recording.

User focus: no additional user-provided focus was present.

Subagent conclusions: the workflow-focused pass proposed the unpinned executable finding; the skill-focused pass proposed the generic mandatory side-effect/subagent finding. I independently verified both against the diff, existing review context, SECURITY.md, and threat-model.md. Final convergence round ended with both subagents reporting NO_NEW_VALUABLE_FINDINGS for this comment set.

that's ok

[github-actions]

PR approved by at least one committer and no changes requested.

[github-actions]

PR approved by anyone and no changes requested.