Non-hex64 directories under <cache>/modules escape the size cap entirely

[MichaelTaylor3d]

Found during the dig-sex fold (parent: https://github.com/DIG-Network/dig_ecosystem/issues/3134, PR #264).

Task

scan_cached_modules skips any directory under <cache>/modules whose name is not a lowercase 64-hex store id. Those bytes are excluded from both the total the sweep measures and the candidate set it can evict.

So the modules cache is bounded at cap only for content the node recognises. Anything else under that directory is invisible to the bound and can grow without limit, while still consuming the same disk the bound exists to protect.

Why it is filed rather than fixed inline

The fix is not a typo correction — it needs a decision about what the sweep should do with content it cannot identify, and there are two defensible answers:

• Count it, refuse to delete it. The bound stays honest about disk consumed, and the sweep evicts more recognised capsules to compensate. Costs recognised content to protect unrecognised bytes, which may be exactly backwards.
• Delete it. Simple and self-correcting, but the sweep would then remove files it does not understand from a directory it does not exclusively own. That is the kind of thing that is fine until the once it is not.

Smuggling either into a refactor PR would have been the wrong place to make that call.

Context

• crates/dig-node-core/src/lib.rs — Node::scan_cached_modules, the hex64 filter.
• Node::evict_modules_locked consumes the scan result as both the total and the candidate set, which is what makes one filter govern both halves.
• The bound this weakens is the #1934 disk-exhaustion bound, whose two regression tests were rewritten in PR feat(cache): fold the tier/relevance/eviction decisions onto dig-sex 0.2 #264 to run the real policy.

Scope

Decide the semantics, then make the total and the candidate set agree with that decision explicitly rather than by both inheriting one filter. State the choice in the sweep's doc comment — the current behaviour is not written down anywhere, which is why it survived a fold that rewrote everything around it.

Evidence

A test that fails without the fix: place a directory with a non-hex64 name holding N bytes under <cache>/modules, run the sweep with a cap below the true total, and assert the outcome matches whichever semantics is chosen. Today the sweep behaves as though those bytes do not exist.

[MichaelTaylor3d]

Fixed on lane loop/batch-cache, draft PR #455, commit 4d5d3cf.

Semantics chosen: COUNT, never DELETE — the ticket's first option.

Reasoning, since the ticket correctly says this needed a decision rather than a typo fix: the sweep does not exclusively own <cache>/modules, and deleting files it cannot identify is the class of thing that is fine until the once it is not. The operator asked for a bound on disk consumed, not for a bound on the subset of the disk this version happens to recognise — so being honest about the total is the property worth keeping, and evicting more recognised capsules is the price. That is exactly the trade the ticket flagged as "possibly backwards"; I take it deliberately, because the alternative's downside is unrecoverable and this one's is not.

Implementation: Node::unrecognised_module_bytes() walks the whole modules subtree and subtracts what scan_cached_modules would return. The two halves therefore partition the subtree by construction rather than by two filters that must be kept in agreement by hand — which is how the original defect arose. The result is charged against the modules share of the budget (see #284).

The choice is stated in the function's doc comment, per the ticket's ask, since nowhere recorded it before.

Test: unrecognised_bytes_under_modules_are_counted_but_never_deleted, asserting both halves separately — a fix could get either one right alone.

The fixture sizing is the load-bearing part and is derived from the split, not guessed: modules share = 7/8 of a 12,288 cap = 10,752. A lone 4 KiB capsule fits that alone, so under the old behaviour nothing is evicted; charging the 8 KiB stray leaves 2,560, which it does not fit. The two worlds give opposite verdicts on the identical fixture. Two in-test assertions pin both sides of that arithmetic, so a later change to the divisor cannot silently make the test vacuous.

My first attempt at this fixture used a 16,384 cap and passed the measurement assertion while the capsule survived — the stray bytes were counted and still fit. Recording that because it is the same shape as the false greens this family keeps producing: the assertion was right and the input could not exhibit the property.

Revert-proof (committed first, reverted by file copy): forcing unrecognised = 0 → FAILED.