Reuse existing extension workflows in isolated software-factory runs

[neubig]

Desired Behavior

Use the existing extensions issue-to-PR, GitHub PR reviewer, and QA Changes behavior in the Docker software factory. Replace the initial duplicated developer/reviewer prompts and raw JSON comments. Adapt only the execution lifecycle and scoped GitHub transport needed for an already provisioned, ephemeral Docker conversation. Keep independent test evidence and guarded merging separate from review presentation.

Acceptance Criteria

• Load existing extension implementation/review/QA instructions from their canonical files, without maintaining duplicate task prompts or a custom review formatter.
• Execute review synchronously in its provisioned Docker conversation and publish the existing native GitHub review with actionable inline findings.
• Keep the host GitHub credential outside workers; expose only the repository and role operations required by the existing workflows.
• Verify that the exact current head received a newly posted review and functional QA report before granting acceptance; keep test logs in artifacts.
• Developer revisions consume actual PR review bodies and inline comments, and preserved work can still be published after a bounded stop.
• Add focused regression tests for the adapter and permission boundaries, and demonstrate the workflow on the live factory.

This issue is ready-for-dev. Depends on #557 and #559. The prior proposal for a custom formatter and rewriting historical reviews is superseded by reuse of the existing extensions.

[github-actions]

✅ ready-for-dev label applied

This issue meets the readiness criteria and is ready for contribution.
A contributor can now open a PR that links this issue (Fixes #<number>).

This is an automated readiness check posted by a workflow.

[neubig]

Ready-for-dev rollout correction: Automation Service deliberately rejects shell metacharacters in entrypoints. Replace the staged env VAR="$VAR" command with a normal --token-env NAME CLI argument, validated against bundle config. This explicitly names the profile-selected secret for SDK injection without relaxing entrypoint validation. Verify the actual Automation API accepts the command and run it in a Docker automation.