Add a Docker-isolated GitHub software factory automation loop

Desired Behavior

The existing issue-to-PR, reviewer, and iterate automations do not form an unattended delivery loop with triage, explicit acceptance criteria, isolated credentials, tested review evidence, and automatic merge.

Acceptance Criteria

• Four reusable roles: issue triage, implementation, independent review/test, and periodic recovery/merge.
• Polling deduplicates by issue state and PR head SHA, and handles an initially empty repository.
• Coding and review use distinct Docker conversations and publish traceable evidence.
• Role-scoped GitHub access restricts each automation to one configured repository and necessary operations.
• Merge requires independent acceptance and successful tests for the current head and refuses stale evidence or failing checks.
• Resource limits and cleanup bound concurrent work.

Readiness

ready-for-dev. The software factory is initially validated against a disposable public repository before general catalog rollout.

Start by inspecting the existing issue-to-PR, reviewer, and iterate automations, then trace how they handle polling, credentials, Docker conversations, evidence, and merging. Validate the design against a disposable public repository first. Done means the four roles, deduplication, isolation, acceptance checks, stale-evidence rejection, resource limits, and cleanup satisfy every listed acceptance criterion.