feat(ble): negotiate an explicit per-peer fragment ceiling

[Chessing234]

Closes the TODO(#1434) left in broadcastPacket when the blanket 256-fragment preflight was narrowed.

The gap

Today the fragment bound for a directed transfer is inferred from the packet type: a directed fileTransfer is assumed to be the raw migration fallback aimed at current Android (256), and anything else is assumed to be aimed at a client whose reassembler is as large as ours. That proxy holds only while "implements the encrypted 0x20 path" and "has a large reassembler" describe the same population.

A client that adopts 0x20 with a smaller buffer breaks it in the silent direction: we plan fragments the peer drops, and the sender sees no local failure. .privateMedia says a peer understands encrypted media; it says nothing about how much of it that peer can hold.

The change

• TLV 0x03 on AuthenticatedPeerStatePacket — a 2-byte big-endian count of fragments the peer will reassemble for one packet, stated inside the established Noise session. Absent means "not advertised", which is what every released client sends, so old peers decode unchanged.
• An unreadable 0x03 (zero, wrong width, duplicated) is rejected rather than skipped like an unknown TLV. Skipping would read as "said nothing", and "said nothing" falls back to the permissive proxy — the opposite of what a peer sending the field is asking for.
• BLEFragmentCeilingPolicy turns the inline type check into a value: packet type + directedness + whatever the peer advertised, out comes the bound and which of three reasons produced it. Framework-free, so every branch is tested directly.
• An advertised ceiling replaces the proxy in both directions. Below 256 is the case the proxy gets wrong silently. Above 256 is a peer telling us the deployed-Android assumption behind that cap does not describe it.
• Every decision is clamped to what we would reassemble ourselves, so one side raising its configuration cannot raise the other side's memory exposure.
• We advertise our own bound too. The receiver's 10_000 guard is now a named constant used for both the guard and the advertisement, so they cannot drift.

Two things worth reviewing closely

The preflight is no longer restricted to fileTransfer. It could not stay restricted and still do its job: an advertised ceiling constrains encrypted media too, and that is the case the proxy misses. Peers that advertise nothing keep the exact old classification, so this is a no-op for every released client.

The rejection copy is now parameterized. It said "more than 256 mesh fragments", which stops being true once the ceiling is negotiated. The existing key is kept and only the numeral replaced, so all 30 locales keep their existing translation. One judgment call I want flagged: Turkish attached a vowel-harmonised ablative suffix to the numeral (256'dan), which no format specifier gets right for every value, so I rephrased that locale to a suffix-free construction (mesh parça sınırı: %lld). That is my edit, not a translator's — please have someone who reads Turkish check it.

Verification

• Full SwiftPM suite: 2018 → 2034, green. The delta is exactly the 16 tests added here (4 wire-format, 9 policy, 3 session-store).
• The rekey invariant is enforced twice over — beginAuthenticatedGeneration drops the observation, and the accessor refuses one pinned to a superseded generation. Removing either alone still passes; the test fails once both are gone, and it was the only failure in that run.
• Two unrelated suites (ChatViewModelInitializationTests, BLEServiceCoreTests) failed once each on runs that took 47s and 63s while the machine was loaded, and did not reproduce in four subsequent clean runs of the full suite or in isolation. Timeout-sensitive, not this diff — but I am flagging them rather than filtering them out.
• No local SwiftLint, so I checked the --strict rules by hand against .swiftlint.yml; one trailing_comma violation found and fixed before pushing.

What I did not verify

No device or simulator run, so the negotiation is verified by unit tests and by reading the wiring, not by two real handsets agreeing on a ceiling. Android does not send 0x03 yet, so in the field today every peer takes the unchanged fallback path — which is the safe way for this to land, but it also means the negotiated branch has no cross-platform exercise until an Android client advertises one.

[Chessing234]

one allocation note while this is open, since i only spotted it reading the rotation spec.

docs/PEER-ID-ROTATION.md §4.5 says the peer-ID binding proof will be "sent as a new TLV in AuthenticatedPeerStatePacket" but never assigns it a number. this PR takes 0x03 there, and the android half is permissionlesstech/bitchat-android#879. so whichever of those lands first should be treated as pinning 0x03, and the binding proof wants 0x04.

worth writing the number down somewhere either way — the packet's TLV space currently has its assignments only in the struct itself, which is how two features end up reaching for the same byte. (the 0x03 in that doc's §4.6 table is the v2 announce's own namespace, not this one — different packet, no conflict.)