Astra: hostfiles path cap, round 2

Round 1 (CODEX-REVIEW-HOSTFILES-CAP.md) raised two P2s. Both are fixed in 826a7a9f; read its commit message.

1. StageDelete takes no cap. It only tombstones an entry the manifest already holds, so an inherited over-cap skipped entry whose file is gone is retired by the next scan.
2. Restore's partition drops a tombstone past the cap. Restore never walks it. Anything standing at that path is left for the next walk, which refuses it with ErrTooDeep.

Tests:

• TestAScanRetiresAnInheritedSkippedEntryPastTheCap covers restore, then scan, then commit.
• TestRestoreNeverWalksATombstonePastTheCap builds a real 2049-level tree at the destination and checks it is left untouched. With the walk restored, it is still running at go test's 10-minute timeout.
• TestRunStopsOnAManifestItCannotCommit now skips its deep path, so it still reaches run's stop branch.

Judge:

1. Are both round-1 P2s closed?
2. Can StageDelete without a cap now admit anything a reader refuses, or retire something it shouldn't, including a live over-cap entry?
3. Is leaving an over-cap tombstone's file on disk safe? It means the next walk refuses the tree. Is that a recovery-stranding path again, through moves' Establish, relocation's flush or the release flush?
4. Anything new?
5. Verdict: is it ready to merge, after the release freeze?

Give findings P1/P2/P3 with file:line. Read-only; run nothing heavy.