MC-4464

RECURRING infra bug. When a pool slot is re-claimed for a new ticket, its git branch is NOT reset to slot{N}/mc-MC-<new-id> — it stays on the PREVIOUS ticket's branch. Worker then sees wrong cwd/branch and either (a) freezes (correct, per circuit-breaker) or (b) risks committing onto another ticket's branch / clobbering its work. Observed: - MC-4457 dispatched to pool-2, but live 'git branch --show-current' = slot2/mc-MC-4455 (previous claimant). Worker froze, nothing committed. Correct stop, but wasted a dispatch. - MC-4431 earlier: pool slots reset from STALE origin/main (Feb-13 77a2275) while live code is master — same family of mis-wiring (pool-claim/409 'unsafe runtime cwd' failures). - mem obs 7192 documents the slot mis-registration. Root cause candidates (confirm): worktree_pool.py claim path not running reset-on-claim, OR reset targeting wrong base ref (origin/main vs master), OR branch-rename step skipped when slot already has a namespaced branch from prior claim. Action: 1. Audit worktree_pool.py claim() — ensure every claim does: fetch, hard-reset to origin/master (NOT stale origin/main), checkout/create slot{N}/mc-MC-<new-id>, verify branch == expected before returning slot. 2. Add a pre-dispatch assertion in mc_pickup.py: refuse to inject a worker if slot branch != slot{N}/mc-MC-<ticket-id>; re-provision instead. 3. Reconcile origin/main vs master base-ref confusion (mission-control deploy uses master). Source: MC-4457 + MC-4431 parked-dispatch evidence. Build via dev-loop; council the claim() reset sequence.