fix(retention): bound metadata-only segment census to one entry

[ScriptedAlchemy]

Problem

At central 27b2d3cc8d58c03d331d7bfdb52519feae18d940, the metadata-only code-generation retention census calls store_holds_generation_segments, which iterates code-generation-segments-v1/ until it finds a valid content-addressed segment or exhausts the directory. A store containing arbitrarily many unrelated, malformed, or crash-debris entries therefore makes the Doctor/storage-report path perform unbounded filesystem work. The callback is checked between entries, but the synchronous Doctor/storage wrapper supplies no cancellation.

The earlier metadata-only fix correctly stopped hashing multi-GiB manifests, but its claimed “bounded directory listing” is not actually bounded. Its contract only needs to distinguish a truly empty directory from one that may hold segment work: any observed entry, including debris, must conservatively retain/return typed Unknown. Exact filename classification is unnecessary here and would require unsafe filesystem cursor machinery.

The adjacent Unix non-UTF-8 filesystem capability probe also treats every write error as “unsupported,” so real failures such as ENOSPC/EACCES can silently skip coverage and emit a captured println! workaround.

Impact

A poisoned or debris-heavy profile can still stall operational diagnostics while enumerating segment metadata, exactly where diagnostics need to remain responsive. The silent probe skip can hide real CI/storage failures.

Acceptance

• An empty or absent segment directory proves NoneFound.
• Inspect at most one directory entry; any observed entry returns typed Unknown/held without filename classification.
• Observe cancellation before accepting the observed entry.
• Keep full-verification deletion fail-closed and unchanged.
• Add deterministic large-debris behavioral coverage proving the census does not exhaust the directory.
• The Unix non-UTF-8 probe skips only the platform/filesystem error that specifically means invalid byte names are unsupported; ENOSPC/EACCES/other write failures fail the test.
• Remove the captured-output println! skip workaround.
• No new cursor format, source-shape assertions, or budget increases.

[ScriptedAlchemy]

Implemented and pushed on codex/fix-segment-census-bound at exact tip e431a43e07142f411d65e94b3836f020a318d7e0.

What changed:

• metadata-only segment census now checks cancellation once and consumes at most one ReadDir entry;
• absent/empty is NoneFound; any observed entry (including malformed crash debris) conservatively remains typed Unknown;
• no filename cursor or exact-classification machinery was added;
• the Unix non-UTF-8 fixture skips only macOS EILSEQ; all other write or cleanup failures now fail the test, and the captured println! workaround is gone.

Evidence:

• deterministic RED: cc-5394 reached the second debris entry under the old implementation and returned Cancelled;
• exact GREEN: cc-5447 and cc-5448 (1/1 each);
• non-UTF-8 journey: cc-5449 (1/1);
• full tracedecay-code-index-retention: cc-5432 (73/73);
• bounded git-correlation suite: cc-5433 (38/38);
• strict all-target Clippy for both packages: cc-5450;
• fmt, diff-check, commitlint, clean worktree, and local/remote SHA equality all verified;
• independent exact-tip review: CLEAN after its sole documentation note was corrected.

The issue should remain open until this exact patch reaches the central branch.

[ScriptedAlchemy]

Merged as 3468599, pushed with 3ac37c2; hauler cc-5989 ran tracedecay-code-index-retention to 81 passed, 0 failed.