fix(airplay): send X-Apple-HKP so pair-setup gets past 400

[snadahalli]

Symptom

With AirPlay Receiver set to Everyone and Require Password off, POST /pair-setup returned 400 Bad Request with an empty body — before the receiver looked at the TLV8 payload at all. GET /info succeeded against the same host, so this was not access control.

This is the third distinct wall on the way to #27, after 403 (AirPlay Receiver set to "Current User") and 470 (Require Password on).

Isolating it

Replayed the request against a Mac running AirTunes/950.7.1, changing one variable at a time:

Request	Result
no Host, FLAGS=0x02 u8 — what this code sent	400
+ Host	400
+ Host, FLAGS=0x10 u32	400
+ Host, X-Apple-HKP: 4, FLAGS=0x10 u32	200, body 409B
+ Host, X-Apple-HKP: 4, no FLAGS	200, body 409B
no Host, X-Apple-HKP: 4, FLAGS=0x10 u32	200, body 409B

X-Apple-HKP is the only variable that matters. It selects the pairing flow, so without it the endpoint rejects the request outright.

Two theories this disproves, both of which looked compelling:

• The missing Host header. HTTP/1.1 requires it and RFC 7230 §5.4 says a server MUST answer 400 without it — but adding it changes nothing, and the request succeeds without it once X-Apple-HKP is present.
• The FLAGS value. The code sends 0x02 in one byte where HAP defines kPairingFlag_Transient as 0x00000010 in a uint32. The receiver ignores the TLV completely — 0x02, a correct 0x10, and omitting it entirely all produce an identical M2.

Since the flag demonstrably does not matter, it is left as-is rather than changed on spec-reading alone; the comment now records the measurement instead of the previous incorrect claim that 0x02 is the transient flag.

Bonus confirmation for #23

The 409-byte M2 decodes as state + 16-byte salt + 384-byte public key. 384 bytes is 3072 bits — independent confirmation that the receiver uses the same RFC 5054 group that #23 installed, from the receiver's own wire output rather than from our tests.

What this does not fix

pair_probe now reaches a genuine M2:

DEBUG M2 received server_pk_len=384 salt_len=16
❌ PAIR-SETUP FAILED: HAP error 2: Authentication failed

So the SRP exchange finally happens, and fails at M4 with the receiver rejecting our client proof. That is a separate bug in the proof computation or the transient password, and is not addressed here.

I probed two candidate divergences (H(g) over PAD(g) vs. minimal encoding, and K = H(S) padded vs. not); both reachable variants still returned error 2, and the rest were masked — see below.

Warning for whoever picks up M4

The receiver backs off hard after a failed pair-setup, answering error 0x03 with a retry delay. Attempts less than a couple of minutes apart return backoff rather than a real answer, and backoff looks nothing like an authentication failure — this silently invalidated a first round of my own results before I noticed. Space attempts generously when bisecting.

Verification

fmt --check clean, clippy --all-targets --all-features -D warnings clean, cargo test --all 216 passed / 0 failed, plus the wire captures above against real hardware.