fix(airplay): complete transient pairing and add the encrypted control channel

[snadahalli]

Stacked on #41 — review that first; this PR's base retargets to master once it merges.

This answers #27. Pair-setup now completes against real Apple hardware, and the encrypted control channel works. It does not produce a working cast, and the reason is at the bottom.

1. The SRP proof hashed g padded

Pair-setup reached M4 and the receiver rejected our proof with HAP error 2. Everything else was right — group, salt, 384-byte server key, session key.

M1 = H( H(N) XOR H(g) | H(I) | s | A | B | K )

H(g) was computed over PAD(g) — g left-padded to N's 384 bytes. It must be g's minimal encoding: the single byte 0x05.

This is an easy mistake to make honestly, because the neighbouring term does require padding: RFC 5054 defines k = H(N | PAD(g)), and that stays padded. The proof has no such rule.

A round-trip test cannot catch this. Both halves compute the same wrong digest and agree — the identical blind spot that let the fabricated group in #23 survive its own round-trip. So the fix changes the test-side server implementation too, keeping the test a proof of agreement rather than a fresh mutual delusion.

Verified: with PAD(g) → error 2; with minimal encoding → SRP-6a verification successful.

2. Transient pairing ran M5/M6

After a successful M4 the code always continued into the Ed25519 identity exchange. Transient pairing ends at M4 — the receiver answered the stray M5 by closing the connection, so a pair-setup that had just succeeded reported Connection closed.

Split the shared SRP half from the identity exchange; transient gets TransientSession { session_key, stream }.

3. There is no pair-verify in the transient flow

negotiate_with_auth ran pair-setup then pair-verify, feeding it long-term keys transient never produces. Pair-verify re-establishes a session from a stored identity; transient has none, and its SRP session key already is the session.

4. The post-M4 channel is encrypted

Verified directly — a plaintext GET /info immediately after M4 gets the connection closed.

control_channel.rs implements it: HKDF-SHA512 from the session key under Control-Salt with separate read/write keys, then ChaCha20-Poly1305 frames of a 2-byte little-endian length. The length is also the AEAD associated data, so a tampered length fails authentication rather than desynchronising the stream. Nonce is a 64-bit little-endian counter, per-direction.

Confirmed by examples/control_probe.rs: pair-setup completes, then an encrypted GET /info decrypts to HTTP/1.1 200 OK, 1395-byte body.

Why this still does not cast

Two independent reasons, and I want both on the record rather than implied by a green build.

The mirror stream cannot encrypt. MirrorStream writes NAL units to a bare TcpStream, but every byte on this connection must now be framed. negotiate_with_auth therefore fails with an explicit message instead of returning a connection that cannot carry video.

The receiver has no endpoint to mirror to. Probed over the working encrypted channel:

Request	Response
POST /stream	404 Not Found
POST /fp-setup	400 Bad Request
SETUP (RTSP)	455 Method Not Valid In This State
GET /server-info	200 OK

/fp-setup answering 400 rather than 404 means the FairPlay endpoint exists and merely rejected an empty body. SETUP reporting a state error rather than 404 means the receiver speaks RTSP but expects that FairPlay step first.

So mirroring to this receiver appears to require FairPlay, which is out of scope by decision (docs/crypto.md) — the same decision that refuses Apple TV 2nd/3rd gen. That is a project-level question, not something to resolve in this PR, but it materially changes what "AirPlay support" can mean here.

Verification

fmt --check clean, clippy --all-targets --all-features -D warnings clean, cargo test --all 220 passed / 0 failed, plus 4 new unit tests on the control channel's nonce layout, key separation, and response parsing — and the hardware captures above.