Post-quantum key support in Kubo

> Filling because I could not find any meta-issue about this

Google published a [threat model for post-quantum cryptography](https://bughunters.google.com/blog/5108747984306176/google-s-threat-model-for-post-quantum-cryptography) with a 2029 migration deadline.

IIUC the near-term risk is store-now-decrypt-later (SNDL): adversaries capturing encrypted traffic today for future decryption. This makes upgrading connection-layer forward secrecy urgent even before quantum computers exist.

NIST has finalized three post-quantum standards relevant to Kubo dependencies (libp2p and IPNS):

| Algorithm | Role | Standard |
|-----------|------|----------|
| ML-KEM | Key encapsulation | FIPS 203 |
| ML-DSA | Digital signatures | FIPS 204 |
| SLH-DSA | Hash-based signatures | FIPS 205 |

Multicodec code points for all three are registered or in review:

- multiformats/multicodec#358
- multiformats/multicodec#392
- multiformats/multicodec#394
- multiformats/multicodec#399

Ongoing spec and implementation discussions:

- Browser Industry (AKA The Google Chrome Monopoly):
- https://chromestatus.com/feature/5198951632470016
- https://wicg.github.io/webcrypto-modern-algos/
- ipfs, `libp2p-key` and things that enable decoupling from `libp2p-key`
- libp2p/specs#710 RFC-0004
- https://github.com/libp2p/specs/pull/711
- https://github.com/multiformats/multicodec/pull/400
- https://github.com/multiformats/multicodec/pull/403

The goal is not to change the default key type away from `Ed25519`; that is a separate decision.

The goal is working, opt-in PQ support well ahead of any forced migration. Large public and private swarms need multi-year upgrade lead time before a new key type can be broadly relied upon. Starting late means the option to migrate gracefully disappears.

**What needs to happen:**

- [ ] libp2p
- [ ] libp2p/specs#710
- [ ] new key type in `go-libp2p`
- [ ] Cross-implementation interop tests (Go / JS) exist
- [ ] go-libp2p release with new key
- [ ] Kubo support in `ipfs key` commands
- [ ] IPNS
- [ ] IPIP to decouple from libp2p and use key codes directly, without `libp2p-key` protobuf wrapper?
- [ ] use PKIX and PKCS#8 "container" rather than libp2p-key?
- [ ] when signing, use IPNS-specific `ctx`
- [ ] Boxo support in `boxo/gateway` and `boxo/ipns` and `boxo/namesys`
- [ ] Kubo support in `ipfs name` commands
- [ ] IPFS
- [ ] Have HTTP-only Kubo mode with identities, routing and retrieval using RFC envelopes and [HTTP signatures (RFC 9421)](https://datatracker.ietf.org/doc/html/rfc9421) instead of libp2p-key-based TLS tunnel/stack

Kubo does not need to wait for libp2p to fix IPNS, we should decouple anyway.