Rebuild repo-contract.wasm to ship the get_state_delta absent-vs-zero fix (requires re-key + migration)

[sanity]

Split out from #62, which fixes the symptom client-side. This issue tracks landing the root fix on the network.

The root bug

freenet_git_types::get_state_delta computed:

summary.extension_seqs.get(k).copied().unwrap_or(0) < v.update_seq

unwrap_or(0) conflates "the peer has never seen this key" with "the peer already holds it at seq 0", so any entry written at seq 0 is undeliverable to every peer, permanently. The same shape was present in the refs loop; refs escaped only because the push path happens to always write update_seq >= 1.

Both loops are corrected in source by #62 (None => true, Some(seq) => seq < entry_seq), with unit tests.

Why that fix is not live

get_state_delta is a contract entry point, so it lives in the compiled WASM. crates/freenet-git/contracts/repo-contract.wasm is a checked-in artifact, last built 2026-04-30 (b8edf90), and CI neither rebuilds nor verifies it against the source. So the source and the deployed contract have already diverged, and the corrected get_state_delta reaches nobody until the WASM is rebuilt.

#62 works around this by writing bundle-tip extensions at update_seq = 1, which is deliverable under the deployed rule. That is sufficient for the observed problem and needs no re-key.

What this issue needs

Rebuilding the WASM changes BLAKE3(wasm), and the contract key is BLAKE3(BLAKE3(wasm) || serialize({prefix})) — so every repo re-keys. That is the documented procedure in legacy_contracts.toml:

1. Capture the BLAKE3 of the currently-committed repo-contract.wasm.
2. Add a legacy_contracts.toml entry for it.
3. Rebuild, copy the new WASM into contracts/, ship.

URLs are prefix-based so they do not change; the legacy-fallback path migrates state on first fetch. But it is a network-wide, one-way operation, so it should be a deliberate decision and is best folded into the next planned contract change rather than done for this alone.

Worth fixing at the same time

• CI does not verify the checked-in WASM matches the source. That is what let the divergence go unnoticed. A job that rebuilds the contracts and compares hashes would turn "source says X, network does Y" into a build failure. Note it cannot simply replace the artifact, since that would re-key silently — it should fail and require the deliberate migration step.
• Once the contract is rebuilt, delete the replicated deployed-rule test in git-remote-freenet (bundle_tip_seq_survives_the_deployed_contracts_delta_rule) and point it at get_state_delta directly. The test says this too.

[AI-assisted - Claude]

[sanity]

🤖 Automated ranking by Torvan. Not a maintainer's assessment of this issue.

Measure	Score
Value	0.718
Cost	0.576
Priority	249 of 593

Value and cost run 0 to 1 across the 593 open issues in the freenet repositories: value 1.00 is the most valuable, cost 0.00 the cheapest. Issues are compared against each other rather than scored in isolation. The queue alternates between the most valuable work and the best value for the effort, so neither expensive-but-important nor cheap-and-quick work crowds the other out.

Ranked 2026-08-31, and liable to change. Adding information here, whether that is scope, a reproduction, or a correction to this assessment, causes the issue to be reassessed and this comment updated.

[sanity]

The gate this issue asks for has landed in #76 (contract-wasm job). It does not close this issue — it makes the gap visible on every CI run instead of letting it grow unnoticed. Two measurements from building it are new information here.

1. repo-contract is stale as described. Confirmed: the checked-in artifact dates from 2026-04-30 (b8edf90) and does not carry the get_state_delta fix its source has held since #62.

2. pack-contract has ALSO already drifted, from workspace input drift alone. This part was not previously known:

• git diff b8edf90..HEAD -- crates/pack-contract is empty, so its source has not changed at all.
• Building at b8edf90 reproduces the committed artifact exactly: 4140e677...
• Building the same unchanged source at HEAD does not: 3439b8a9...

So the address moved without a single source edit, purely from shared-lockfile and toolchain drift across the workspace. Per #64, pack-contract has no legacy-migration path, so a silent re-key of it orphans all history with no fallback.

Why this matters now: Dependabot was enabled across the org, so freenet-git will receive a grouped cargo PR monthly. pack-contract and repo-contract are workspace members sharing one Cargo.lock, so a bump anywhere in the workspace moves both. Measured: cargo update -p blake3 alone (1.8.5 to 1.8.7, a nine-line lockfile diff) changes both contracts' compiled hashes, while fmt, clippy, test and fixture-tamper-check all stay green.

The new job records four hashes and keeps two distinct facts apart: the two checked-in artifacts, which are the live addresses, and the two compiled-from-source results, which ship nothing and exist only as the drift detector. It never rewrites an artifact, since that would re-key silently. Builds are made machine-independent with --remap-path-prefix plus a pinned toolchain, verified by CI computing the same hashes as a local build.

Still needs a human decision, unchanged by any of this: closing the artifact-vs-source gap means rebuilding and shipping, which re-keys every repo and every pack on the network. That is the migration call this issue exists for.

[AI-assisted - Claude]