The restore clones as many repositories at once as the machine has cores for #2624

CLONES = 4 in src/snapshot/restore.ts is fixed. On the forge's machine a snapshot with hundreds of repositories spends most of the drill's minutes cloning bundles four at a time.

Done looks like:

• [ ] restoreSnapshot takes options.clones. When it is unset it uses Math.max(2, Math.min(16, availableParallelism() - 1)) from node:os. The restore command (bun src/snapshot/restore.ts) accepts --clones N (1–32, anything else refused with a message).
• [ ] A failed clone still names the earliest bundle in the manifest, however the clones raced.
• [ ] Tests: with a stub git that records how many clones run at once, clones: 6 never exceeds 6 and does reach it with 20 bundles. --clones 0 and --clones x are refused.
• [ ] docs/RECOVERY.md's Route 1 mentions --clones. Run bun x tsc --noEmit and the snapshot-restore tests.

Parked by the crew: the check failed ("the doc's restore command is the one restore.ts prints") and the decider saw no point in another try (pull #2626 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.