feat(protocol): add peer ID rotation phase 1

[a1denvalu3]

Summary

• implement the peer-ID rotation HKDF/HMAC, X25519 recognition-tag, fixed tag-block, epoch-window, and Ed25519 binding primitives
• add strict announceV2 (0x2C) TLV encoding/decoding and advertise capability bit 14 in existing v1 announces
• parse and discard v2 announces in Phase 1 so unsigned presence cannot establish liveness, enter the people list, or be gossip-relayed
• document Android positions on O1/O4/O5/O7 and pin proposed joint binding-signature and full-packet vectors

Interoperability vectors

The JVM tests reproduce all three published section 7 values byte-for-byte, including the directional recognition tags. They also pin independently generated joint vectors with fully documented fixed inputs so iOS can reproduce them from the prose.

Rollout and risk

This is additive Phase 1 only. Android continues to emit v1 announcements and use stable IDs; no rotating ID is used by the shipping mesh. The primary compatibility risk is the new capability advertisement and message-type recognition.

Validation

• ./gradlew testDebugUnitTest lintDebug
• ./gradlew :app:assembleDebug :wear:assembleDebug clientRewriteContractTest
• focused peer-ID rotation, announce-v2, and capability vector tests
• Mesh Lab: blocked. This PR does not emit v2 on air. A regression handoff is broadcast, dm, and raw after authorized setup.

Refs #848

[Chessing234]

checked the allocations against the ios side: announceV2 = 0x2C and bit 14 both match docs/PEER-ID-ROTATION.md §4.6/§5 exactly, including the reasoning for skipping 11–13. good.

the thing i'd push back on is advertising it. LOCAL_SUPPORTED now includes PEER_ID_ROTATION, but phase 1 parses v2 announces and throws them away. in the ios flow that bit is the signal a peer uses to decide rotation is safe — step 1 of §5 is "A hears an announce from unknown peerID_e advertising the rotation capability". so an ios build that implements rotation, sees this bit, and starts rotating becomes invisible to this client, because the announces carrying its new IDs are exactly the ones being discarded. that failure is silent and looks like the peer left.

it also cuts against the rule #876 is adding to ANNOUNCEMENT_GOSSIP.md in parallel — "implementations advertise only wire features they implement". parsing-and-discarding isn't implementing.

phase 1 reads fine without the advertisement: keep the constant, keep the parser, keep the vectors, and add the bit to LOCAL_SUPPORTED in the phase that can actually act on a rotating peer.

smaller: the spec says whoever implements first "pins the number in a shared test vector", and ios's PeerCapabilities.swift still has nothing at 11–14, so right now bit 14 exists only in a doc paragraph and in AnnounceV2Test here. worth flagging on the ios side so the number is claimed in both claim tables rather than one.