Adopt dig-sex 0.4 and give tier-0 selection the residency it needs -- run_round knows nothing about what is held

[MichaelTaylor3d]

Task

Adopt dig-sex 0.4 in dig-node-core and thread residency into tier-0 selection.

This is not a mechanical version bump, and treating it as one silently defeats the change it adopts.

Why

dig-sex 0.4 makes the displacement margin reachable — SPEC 8.5's named primary defence against attacker-driven cache thrashing, previously implemented, tested, and unreachable through the only API a consumer calls.

It required two facts to reach selection, not one: the margin itself, and per-candidate incumbency. A margin alone cannot work, because hysteresis is a comparison between an incumbent and a challenger — a candidate set that cannot tell them apart cannot apply a margin whatever value it is handed.

The trap

tier0_prefetch::run_round has no residency information at all today. It samples from DHT probes, scores, selects and fetches with nothing consulting what is already held.

So resident: false would compile, would pass, and would reproduce exactly the churn the margin exists to stop — while the API now looks correct. That is the same defect one layer deeper and harder to see.

The call site

crates/dig-node-core/src/tier0_prefetch.rs, in run_round:

• line ~410 gains resident: held.contains(&sc.content_id)
• line ~420 becomes select_within_capacity(&selector_cands, SelectionPolicy::new(budget, SelectionSeed::from_peer_id(&node.peer_id)))

Thread the held-set in as an argument. run_round is deliberately pure — that purity is what fixed the #1991 parallel-runner env race — so the held-set joins the already-injected enabled / load / rate rather than being read from a global.

TieredPolicy::new is unchanged, so its two call sites need nothing.

Two minors, not one

Cargo.toml:348 still pins dig-sex = "0.2" while the crate is at 0.4.0. The 0.3.0 crate-root re-export work is also unadopted, so this covers both jumps.

Acceptance bar

A re-sampled already-held candidate is not re-fetched. That is the behaviour the margin buys and the only thing that proves the adoption is real rather than typed.

A test asserting resident is populated is not enough — it must assert the outcome, because a wrong-but-compiling resident: false passes any test that only checks the field exists.

Parent

Orchestrator epic: https://github.com/DIG-Network/dig_ecosystem/issues/3138

[MichaelTaylor3d]

Verified ALREADY SHIPPED — not rebuilding (§2.0 already-shipped check)

Measured on loop/batch-digsex off origin/main @ 3e480dd. Every element this ticket asks for is present, and the version claim in the body is stale.

The dep. Body says Cargo.toml:348 still pins dig-sex = "0.2". It does not: crates/dig-node-core/Cargo.toml:509 declares dig-sex = "0.5". Latest published is 0.5.0 (index.crates.io/di/g-/dig-sex), so the crate is current, and 0.4 — the version this ticket names — is two behind.

The residency thread. run_round takes held: &HashSet<[u8; 32]> as an argument (tier0_prefetch.rs:389), exactly the injected-not-global shape the body asks for, with the #1991 rationale recorded in its doc comment.

resident is populated from it — tier0_prefetch.rs, resident: held.contains(&sc.content_id) — and select_within_capacity is called with SelectionPolicy::new(budget, SelectionSeed::from_peer_id(&node.peer_id)).

The held-set is real, not empty — which is the thing worth checking, because resident: false everywhere would compile and pass. NodeHeldCapsules::held_content_ids (tier0_live.rs:423) enumerates the real cache via cache_list_cached() and re-derives each id as ContentId::capsule(store, root).to_key(), and the live loop re-reads it every round (tier0_live.rs:561) rather than snapshotting at spawn.

The acceptance bar is asserted as an OUTCOME, not as a field. an_already_held_candidate_is_not_refetched_while_an_unheld_one_still_is (tier0_prefetch.rs:695) asserts already_held == 1 and cached == 1 — it varies one candidate and keeps an honest unheld control, so a blanket resident: false fails it rather than passing it.

Closing as satisfied. #268 / #269 / #271 remain genuinely unwired and are in flight on PR #456.