OPS-01: Fuzz nightly CI failing since 2026-05-20 — reconcile uncommitted fuzz.yml/Cargo.lock/README + diagnose

[DrunkOnJava]

Problem

Nightly fuzz workflow has failed 3 consecutive runs:

• 2026-05-20 run 26150803463 (27s)
• 2026-05-21 run 26214739771 (28s)
• 2026-05-22 run 26277063502 (25s)

All three fail in 25-28s — well before the 300s libFuzzer budget
— suggesting a setup-time failure, not a crash.

There is also uncommitted in-progress work on the fuzz tooling
in the working tree:

• .github/workflows/fuzz.yml — adds fuzz_placement_subblock_2024
  target + changes cargo install cargo-fuzz to cargo +stable
• fuzz/Cargo.lock — minor
• fuzz/README.md — documentation refresh (scaffold notes ->
  current-targets list, mentions fuzz_elem_table not currently
  present in workflow matrix)
• TODO.md — 3-line addition under M8-04 about Node 20
  deprecation audit

Likely root cause: cargo install cargo-fuzz --locked on
nightly toolchain failed when a transitive dep stopped
supporting nightly's MSRV, or vice versa. The uncommitted
cargo +stable install is the fix-in-progress.

Scope

• Reproduce locally: cargo +stable install cargo-fuzz --locked and confirm it works.
• Decide on fuzz_placement_subblock_2024 / fuzz_elem_table
  status — either land them as proper targets or remove from
  README/workflow.
• Commit reconciled diff atomically (or back out cleanly).
• Re-trigger nightly run via gh workflow run fuzz.yml and
  confirm green.

Acceptance criteria

• Next nightly fuzz run completes successfully.
• Workflow matrix == README target list (no drift).
• No remaining uncommitted fuzz changes after this issue
  closes.

Related

• Per ROADMAP SAFE-03/SAFE-04 (fuzz hygiene)
• Touches supply-chain expectations from M8-04: Keep supply-chain policy enforceable #55 (closed M8-04)