deps: migrate to multihash-codetable 0.2 (escape yanked core2)

[onehumankindness]

Migrate to multihash-codetable 0.2.x

The current multihash-codetable = "0.1" dependency pulls in
core2 ^0.4.0 transitively, which has been yanked from crates.io
(every published version of core2 is yanked). This makes the whole
beetswap dependency graph unresolvable for downstream projects — a
fresh cargo build of any crate that depends on beetswap 0.5.0
fails with:

error: failed to select a version for the requirement `core2 = "^0.4.0"`
  version 0.4.0 is yanked
  required by package `multihash-codetable v0.1.0`
    ... which satisfies dependency `multihash-codetable = "^0.1"`
        of package `beetswap v0.5.0`

multihash-codetable 0.2.x replaced the core2 no-std I/O abstraction
with digest-io and bumped the underlying digest trait from 0.10 to
0.11, but the public surface beetswap uses — the Code enum, the
MultihashDigest trait, Code::try_from(u64), .digest(bytes) — is
preserved.

Changes

• Cargo.toml: bump multihash-codetable from "0.1" to "0.2" in
  both [dependencies] and [dev-dependencies].
• Drop the "digest" feature flag from the dev-dependency — it does
  not exist in multihash-codetable 0.2.x.
• No source-level changes required. cargo build and cargo check
  succeed unchanged.

Verification

Built the migrated Cargo.toml against multihash-codetable 0.2.2
with rustc 1.96.0 for two musl-static targets:

• x86_64-unknown-linux-musl: builds clean in 24s, ldd reports
  "statically linked".
• aarch64-unknown-linux-musl (Raspberry Pi 4, NixOS): builds clean,
  ldd reports "not a dynamic executable".

cargo audit no longer flags the yanked-core2 issue.

Motivation

We're using beetswap as the sovereign blob transport in a downstream
networking project. The yanked-core2 issue is currently a hard blocker
for our integration work; we've been carrying this delta as a
transitional fork in our workspace. Submitting upstream rather than
maintaining a fork in perpetuity, per the adopt-and-contribute-first
principle.

If the maintainers prefer a different approach (e.g. waiting until a
broader digest 0.11 / multihash major bump, or pinning to a specific
mhc 0.2 minor), happy to adjust.

Thanks for maintaining beetswap.