chore(deps): bump h2 to 0.4.17 (RUSTSEC-2026-0258)

[Nic-dorman]

Summary

Lock-only bump of h2 0.4.14 → 0.4.17 to clear RUSTSEC-2026-0258 ("h2 unbounded empty DATA frames", published 2026-08-17, fix ≥0.4.16), which has the Security Audit job red on main and on every open PR as its CI re-runs (currently visible on #153). Same advisory, same treatment as ant-node#209 (V2-1023) and the ant-sdk lockfiles (V2-1035) — saorsa-core was the repo left behind.

Nothing here depends on h2 directly; it arrives via hyper behind reqwest and igd-next under saorsa-transport. Per the V2-1023 analysis the practical exposure is the igd-next UPnP client (the one dependent that enables hyper's http2 feature) being fed empty DATA frames by something on the LAN posing as the IGD gateway — small surface, two-line fix.

The lock entry is hand-edited (version + checksum only) rather than taken from cargo update -p h2, which drags along a windows-sys 0.52/0.60/0.61 reshuffle across the QUIC and filesystem stacks — the same churn V2-1023 explicitly avoided. The 0.4.14 and 0.4.17 entries have byte-identical dependency lists.

Linear issue

V2-1041 — https://linear.app/autonominetwork/issue/V2-1041/saorsa-core-bump-h2-0416-in-cargolock-rustsec-2026-0258-security-audit

Risk tier

• T0 — docs / tooling / CI / pure UX-output. Repo CI only.
• T1 — client-only, no network-facing behavior change. CI + prod compat smoke.
• T2 — node/client logic with behavioral surface, no protocol/format/economics change. Dev testnet + ADR.
• T3 — protocol / storage format / payments / routing. T2 evidence + adversarial testing.

(Same tier as ant-node#209 for the identical change: a patch-level transitive dep bump, no saorsa protocol surface.)

Compatibility

• Wire: none
• Storage: none
• API: none — Cargo.lock only; no manifest or source change.

Semver impact

• breaking
• feature
• fix

Test evidence

• cargo metadata --locked: accepts the hand-edited lock without wanting to rewrite it; cargo update -p h2 --dry-run finds nothing to change.
• Checksum provenance: the 0.4.17 checksum was taken from cargo's own resolution (cargo downloaded and verified h2-0.4.17.crate against the crates.io index during a scratch cargo update -p h2; the hand edit reuses exactly that entry).
• cargo test --lib: 521 passed, 0 failed, 2 ignored (Windows, rustc 1.97.1).
• CI's Security Audit job on this PR is the end-to-end verification that the advisory clears.

New dependency

none — version bump of an existing transitive dependency; the 0.4.14 → 0.4.17 lock entries have byte-identical dependency lists.

ADR

n/a (Tier 1).

Mitigation / rollback

Revert the commit. It touches nothing but Cargo.lock (2 lines), so there is no migration and no stored-data or wire implication either way.

🤖 Generated with Claude Code

[dirvine]

Review verdict: APPROVE at 8dc8a572faa044b507e31dfd2ead3d1f7e3abf91.

The lockfile-only update moves h2 from 0.4.14 to 0.4.17, removing the version affected by RUSTSEC-2026-0045; no unrelated dependency changed. GitHub's Security Audit is green. Local verification: cargo test --lib — 525 passed. I found no blocker.

The only current red check is claude-review, which appears to be reviewer/integration infrastructure rather than a repository test failure.