Extend GitHub issue-to-PR for profile-backed continuous development

[neubig]

Desired Behavior

Extend the existing github-issue-to-pr automation with a lightweight scanner that delegates every ready issue and failed-review revision as an independent subject turn. The scanner must not create, attach, or poll conversations. The Automation service owns conversation routing and runtime lifecycle; the profile-backed agent owns checkout, implementation, tests, push, and pull-request publication inside its sandbox.

Acceptance Criteria

• The existing extension selects ready, dependency-complete issues and exact PR heads that failed review.
• Eligible subjects fan out through stable repository-and-issue identities with idempotent revisions.
• The canonical implementation prompt is reused for both initial work and revisions.
• The scanner contains no Agent Server URL, session key, conversation attachment, runtime polling, workspace-kind branching, or Git publication coordinator.
• The agent requests independent review after opening or revising a PR.
• Focused tests plus live validation on the Airbnb demo show multiple agents working concurrently.

[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]

Follow-up from #571 review: consider bounded retries for push/PR publication after the agent has finished. This behavior predates the SDK API narrowing. A transient publication error currently fails the run; the next scheduled run may repeat implementation. It does not delete the failed run’s committed checkout: _checkout_path includes the conversation UUID, and a later dispatched run has a distinct conversation/workspace. The existing _open_pull_request already recognizes an existing PR after a 422 response.

The legacy _finalize_task retry logic is tied to poller records, cloud-API callbacks, and its own conversation lifecycle; importing it into the profile-dispatched worker would duplicate the Automation/SDK lifecycle. Any follow-up should retain those boundaries and reuse the existing Git/publish helpers. Validate transient push and PR failures, ambiguous successful PR creation, bounded exhaustion, and no repeated agent implementation within the same run. This is operational resilience work, not a regression from the constructor migration.