Astra: hostfiles path cap, round 3

Round 2 (CODEX-REVIEW-HOSTFILES-CAP-2.md) raised one P2. When Restore skipped an over-cap tombstone, it left the deep file on disk, so the next scan refused the tree and relocation's flush stuck.

Fixed in 3ab48ff7 and cc1c3d24, then merged with main in b3fa7427:

• removePastCap (internal/hostfiles/restore_unix.go) removes an over-cap tombstone's file in one linear walk: - root.Open(".") to get a descriptor; - descendCtx, which is dir_unix.go's descend with a ctx check per component, using openat ONOFOLLOW|ODIRECTORY per component; - a plain-final-name check, then unlinkat; - an fsync of the parent through the held fd.
• Deep tombstones are never mark()ed. Under-cap tombstones still use removeInside.
• restore_other.go is the !unix stub, and it errors.
• platform-1e's census ruling hostfiles-cap-236 is folded in. Its conditions are in the overlay internal/provision/testdata/plan14-root-reads-hostfiles-cap-236.tsv.

Tests (fix5_linux_test.go, internal/host/relocationflush_deeptombstone_linux_test.go):

• A 2048-level removal takes about 25ms.
• Cancellation stops mid-walk.
• A symlink is never followed, at depths 0, 1024 and 2047.
• A non-plain final name refuses.
• Restore, then ReleaseFlushFiles.Flush, commits.

Judge:

1. Is round 2's P2 closed?
2. Durability: is an fsync of only the immediate parent enough, given no ancestor's entries change?
3. Do the ruling's five conditions hold in the code?
4. Races: can a concurrent rename or symlink swap during the walk make it remove anything outside the tombstone's own path, or anything that isn't a non-directory?
5. Anything new?
6. Verdict: is it ready to merge?

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