Round 1 (`CODEX-REVIEW-HOSTFILES-CAP.md`) raised two P2s. Both are fixed in 826a7a9f; read its commit message.
4
5
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.
6
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.
7
8
Tests:
9
- `TestAScanRetiresAnInheritedSkippedEntryPastTheCap` covers restore, then scan, then commit.
10
- `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.
11
- `TestRunStopsOnAManifestItCannotCommit` now skips its deep path, so it still reaches run's stop branch.
12
13
**Judge:**
14
1. Are both round-1 P2s closed?
15
2. Can StageDelete without a cap now admit anything a reader refuses, or retire something it shouldn't, including a live over-cap entry?
16
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?
17
4. Anything new?
18
5. **Verdict:** is it ready to merge, after the release freeze?
19
20
Give findings P1/P2/P3 with file:line. Read-only; run nothing heavy.
amadan