fix(protocol): push a key package again when it produced no session

[mizanisoffline]

Summary

A lost key package could leave two peers without an MLS session forever.

The engine pushed its key package to a peer once, recorded the peer in key_package_sent_to, and returned early on that record at every later discovery. A carrier that lost that one frame therefore lost the exchange for good. Two peers that dial each other at once hit this routinely: each announces the peer on the first peer stream and pushes its key package there, the second stream supersedes the first, and the superseded stream's late frames are dropped without a loss report (as docs/spec/stream-framing.md, "What a receiver owes", requires). If both pushes were on it, the stream stays up, no session ever forms, and queued messages end in Max retries exceeded.

Found on a device: an iPhone running the Network-framework peer-stream manager against the Python host. About 1 in 5 fresh first contacts reproduced it. Logs from the failing round show both streams superseded at connect, then no key-package, Welcome or session event on either side, and a message queued indefinitely. The same race exists between two Python hosts, which both dial too.

Fix (crates/offline-protocol/src/protocol/):

• When each push happened, and how often it was repeated. key_package_sent_to is now a map from peer to (instant of the last push, repeat count). It keeps its existing size limit.
• Re-arm. rearm_key_package_for_peer (in session.rs, next to rearm_welcome_for_peer) pushes again when no MLS session exists with that peer and the last push is older than the backoff window: 30 seconds (KEY_PACKAGE_RESEND_INTERVAL_SECS), doubling with each repeat up to 10 minutes (KEY_PACKAGE_RESEND_CAP_SECS, pinned to the Welcome retry ceiling).
• Two triggers. It runs at the early return in on_neighbor_discovered_via, and from the reconciliation tick for every peer with messages queued behind a session. The second covers a quiet pair that is never rediscovered.
• Bounds.
  • A confirmed session returns before anything else, from memory. Discovery runs on every inbound body, so an established peer never reaches MLS storage on this path.
  • The window is stamped before the storage check and before the send. An unconfirmed session, a failing storage read or a send that keeps failing costs at most one check per window, not one per frame.
  • Any session, confirmed or not, stops the push. An unconfirmed session stays with the Welcome lifecycle and the confirmation probes.
  • The backoff means a peer that never answers (an old SDK, encryption opted out, a group member with no 1:1 session) settles at one push per 10 minutes. A reset push, or forgetting the peer (session reset, neighbour lost), starts it over.
  • The first push is unchanged.
• ADR 0012 still holds. The pool hands a peer its own live package until a Welcome consumes it, so the repeat push mints no key material.
• Receivers are unaffected. The repeat push carries session_reset = false, so a receiver only refreshes its stored copy and never tears down or replaces a session.

Not covered:

• A lost reset push (re-key, unblock). The repeat carries no reset, so a peer that kept its session keeps it. Repeating the reset flag would tear down a replacement session whose Welcome is in flight, so this belongs with the split-session work below.
• A related variant seen once, where both sides hold a session for the pair but disagree on it (INVALID_CIPHERTEXT on every message). The re-arm stops as soon as a session exists, and ADR 0006 deliberately triggers a re-key only on an epoch mismatch. That needs its own investigation.

Docs:

• docs/state-machines/session-lifecycle.md: a new transition, and a section stating the invariant, the failure it prevents, the bounds and backoff, and the lost-reset limit.
• CHANGELOG.md: an entry under [Unreleased] / Fixed.
• The group capability probe comments (data_sync.rs, send.rs) now say a probed member is repeated only on the re-arm backoff.

Type of change

• fix — bug fix
• test — adding or correcting tests

Testing

New tests in crates/offline-protocol/src/protocol/tests/mod.rs, using the existing two-engine harness:

• a_lost_key_package_is_pushed_again_on_rediscovery
• a_lost_key_package_is_pushed_again_from_the_tick_while_a_message_waits
• a_key_package_is_not_pushed_again_inside_the_interval_or_once_a_session_exists: also checks that an unconfirmed session found in storage re-stamps the window without pushing
• a_key_package_repeat_backs_off: the doubling, and the cap checked on key_package_resend_wait_secs directly

Each drops both engines' first key packages, then checks recovery or the bound. No test ages a stamp by more than about a minute: Instant counts from boot, so a ten-minute offset does not exist on a freshly booted CI runner.

Applied to main without the fix, the recovery tests fail: the queued message never arrives, and no session forms. With the fix they pass.

Checklist

• cargo fmt --all -- --check passes
• cargo clippy --workspace -- -D warnings passes
• cargo test --workspace passes (32 suites, 3,206 tests, doctests included)
• RUSTDOCFLAGS="-D warnings" cargo doc -p offline-protocol --no-deps passes
• cargo-deny is satisfied (no dependency changes)
• Commits follow Conventional Commits
• Docs / CHANGELOG.md updated
• No new unsafe
• UDL unchanged; no binding regeneration needed