# 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.