build(deps): update bincode requirement from 1 to 3

[dependabot]

Updates the requirements on bincode to permit the latest version.

Commits

• See full diff in compare view

[sanity]

This cannot build: bincode 3.0.0 is a compile_error! stub, not a release

Not closing this — leaving the disposition to a maintainer — but flagging it so nobody spends an hour on it.

bincode 3.0.0 (published 2025-12-16, current and not yanked, which is why Dependabot proposes it) is a protest/placeholder release whose entire src/lib.rs is:

compile_error!("https://xkcd.com/2347/");

So cargo build fails outright the moment the dependency resolves. Verified by building against it:

error: https://xkcd.com/2347/
 --> .../bincode-3.0.0/src/lib.rs:1:1

This is not a wire-compatibility question or a migration effort estimate. There is no code in the crate to migrate to.

If a bincode upgrade is ever wanted

The last real release is 2.0.1 (2025-03-10), and it is not wire-compatible by default. Measured against 1.3.3 on a simple two-field struct:

config	bytes	compatible with 1.3.3
config::standard() (2.x default, varint ints)	fb 2c 01 fc 70 11 01 00	no
config::legacy()	2c 01 00 00 70 11 01 00	yes, byte-identical

That matters more here than in most crates: bincode is the encoding of the host↔delegate wire (InboundDelegateMsg / OutboundDelegateMsg), and a delegate's decoder is frozen once its WASM is deployed. Adopting 2.x's default config would silently change the encoding of every already-deployed delegate's messages. Only config::legacy() is a safe target, and switching to it would need the wire pins in delegate_wire_compat re-run as the gate.

The actively-maintained successor is published under a different crate name (bincode-next), so a real migration is a rename, not a version bump — worth its own issue rather than a Dependabot PR.

See docs/wire-format.md (freenet-stdlib#129) for the wire rules this interacts with.

[AI-assisted - Claude]