# Astra: hostfiles path cap, live entries only

Branch `hostfiles-cap-live-entries`, commit 28d086d8, from main 132cf996. Read the commit message first.

**Background.** Moves' Astra review of a8cebad, posted on amadan #236, found a P2. `checkManifest` capped every entry path at 4095 bytes, tombstones and skipped entries included. A manifest written before the cap could therefore stop `Establish` with ErrTooDeep and strand a moves recovery after a cut.

**The change:**
- The cap now applies only to live entries. The rule is `LiveEntriesWithinCap`, exported; internally it is `manifestWithinCap`.
- Readers (`checkManifest`), Open, OpenAt and Commit all apply it.
- New writes still refuse over-cap paths: Stage, StageSkipped, StageDelete and the walk.
- A census overlay records the Plan 14 envelope change.

**Judge:**
1. Is exempting tombstones and skipped entries safe in every reader and writer?
   - Restore's tombstone removal, `removeInside` with `realParents` and `os.Root` `Lstat`/`Remove`, now receives over-cap paths. Can that fail with ENAMETOOLONG, or cost unboundedly? Would the failure be any worse than the old ErrTooDeep refusal?
   - Check `superseded`, `Present`/`presentFile`, `CopyManifest`, `NewFromCopy`, and moves' `movesFilesAllowed` / `Establish`.
2. Is there any reader or writer still applying the old all-entries cap that would strand the same recovery?
3. Does anything still let a new over-cap live entry be written?
4. Are the tests sufficient? Is the census overlay correct and envelope-only, with no root-read unit or legacy seal change?
5. **Verdict:** is it ready to merge, after the release freeze?

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