Route replicate to bootstrap when a resume marker survives on the target

An interrupted batched bootstrap leaves refs/gitsync/bootstrap/heads/<branch> on the target so the next run can resume. Under replicate --prune that marker was just an undesired target ref, so replicateCanBootstrap returned false and the repo was routed to replicate — a single unbatched pack — on every subsequent sync. The artifact of the one strategy that can resume was exactly what locked that strategy out (ENT-2054; ENT-1948 is one instance).

The marker namespace has one writer — batched bootstrap, which deletes its marker on finalize or when stale — so a surviving marker is a positive signal: a bootstrap started and did not finish. replicateBootstrapRoute now routes on that signal ahead of the emptiness heuristic, requiring only that every desired target ref is absent (the bootstrap planner refuses existing desired refs), and deliberately ignoring other stray target refs so an aborted push or a branch deleted upstream mid-bootstrap cannot re-wedge the repo. The reason is threaded through dry-run too, so a plan against a stranded repo reports bootstrap-resume-marker directly.

On the one partial shape the route cannot take (some desired branch complete, another mid-flight), replicate stays the executor; its prune plans now skip markers that still carry resume state so best-effort runs cannot destroy the resume position. Stale markers — branch complete or gone from the desired set — remain prunable.

Deliberately NOT reordering replicate's deletes ahead of the update pack (floated in ENT-2054): the update-then-delete order is load-bearing for mirror-worker's default-branch rename recovery, which relies on the replacement branch existing before entiredb rejects the current-branch delete. With routing fixed, marker cleanup no longer gates anything.