The restore drill records how long each part took — download, decompress, open, migrate — and its budget follows the snapshot's size #2719

The half of #2667 that pull #2670 does not deliver.

Done:

• [ ] the drill log and the card's detail name each part's time ("download 8 min, decompress 40 s, …")
• [ ] download streams into decompression; the drill's budget scales with the snapshot's size, and the per-get deadlines × attempts never exceed it
• [ ] test: a 400 MB snapshot through a throttled fake store restores within budget and its card names the slowest part

Files: src/snapshot/*.

Parked by the crew: the check failed ("(unnamed)") and the decider saw no point in another try (pull #2730 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the check failed ("following across forges, end to end > the whole path") and the decider saw no point in another try (pull #2732 closed).

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check failed ("(unnamed)") and the decider saw no point in another try (pull #2730 closed)
2. the check failed ("following across forges, end to end > the whole path") and the decider saw no point in another try (pull #2732 closed)

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

State: split. Both pulls failed the check on unrelated tests after trying to measure, stream and re-budget in one change. The fresh issues each do one: time each part (#2742), stream download into decompression (#2743), and a drill budget that follows size (#2744). #2667 now waits on them.