Sentinel: drill was degraded 1440 minutes today: The last restore drill passed with 3 min 10 s to spare; download took 13 min 35 s of it. #3115

I raised the number of downloads a restore runs at once from 8 to 24. This is untested against real downloads, so I don't know it clears the sentinel's finding. The type check didn't run in this sandbox (bun install couldn't write its tempdir, so there were no types). The restore-parallel test file and the drill tests passed (73 tests), and the forge's check will run tsc on the push.

Why: the last drill passed with 3 min 10 s to spare, and 13 min 35 s of it was download. The board reports any drill that uses more than 80% of its budget as degraded. Restore downloads shared the upload's limit of 8 gets in flight, a limit set because uploads were bound by latency. Downloads of thousands of objects are bound the same way.

What changed:

• src/snapshot/restore.ts now has its own RESTORE_IN_FLIGHT = 24. Uploads stay at 8.
• The 64 MiB cap on bytes held in memory is unchanged, so memory use stays bounded.
• test/snapshot-restore-parallel.test.ts now expects reads to go past 8 but never past 24.

What I left out:

• I didn't loosen the 80% warning or grow the time budget. Either would hide the finding without making the restore faster.
• I couldn't measure real download throughput here. If the next drill is still slow, the link is probably bandwidth-bound and the next step is to look at the store's throughput. Treat this as a first step.

To try it: bun test test/snapshot-restore-parallel.test.ts. The real check is the next drill, where the "drill" entry should stay off the degraded list or finish under 10 minutes.

Closes #3108

I raised the number of downloads a restore runs at once from 8 to 24. This is untested against real downloads, so I don't know it clears the sentinel's finding. The type check didn't run in this sandbox (bun install couldn't write its tempdir, so there were no types). The restore-parallel test file and the drill tests passed (73 tests), and the forge's check will run tsc on the push.

Why: the last drill passed with 3 min 10 s to spare, and 13 min 35 s of it was download. The board reports any drill that uses more than 80% of its budget as degraded. Restore downloads shared the upload's limit of 8 gets in flight, a limit set because uploads were bound by latency. Downloads of thousands of objects are bound the same way.

What changed:

• src/snapshot/restore.ts now has its own RESTORE_IN_FLIGHT = 24. Uploads stay at 8.
• The 64 MiB cap on bytes held in memory is unchanged, so memory use stays bounded.
• test/snapshot-restore-parallel.test.ts now expects reads to go past 8 but never past 24.

What I left out:

• I didn't loosen the 80% warning or grow the time budget. Either would hide the finding without making the restore faster.
• I couldn't measure real download throughput here. If the next drill is still slow, the link is probably bandwidth-bound and the next step is to look at the store's throughput. Treat this as a first step.

To try it: bun test test/snapshot-restore-parallel.test.ts. The real check is the next drill, where the "drill" entry should stay off the degraded list or finish under 10 minutes.

The full gate on land was red and named no test; the pull is open again.