fix(protocol): a resend is offered to the mesh when no carrier reaches the recipient

[bahdotsh]

Problem

Only a message's first send is handed to mesh neighbours when no carrier reaches the recipient: handle_send_failure offers it when no carrier took the frame, and handle_send_success offers it when a carrier took it for a recipient it cannot reach. The resend paths asked neither question:

• the retry loop in process_retry_queue (protocol/mod.rs), both branches;
• try_flush_send_via, behind flush_outbox_all and flush_outbox_for_peer_via, both branches.

So a message whose first attempt went into a direct link that had already died (a half-open stream accepts frames until its keepalive notices) was never carried. By the time its acknowledgement timed out the link was gone, every resend was refused and went back on the retry queue, and a neighbour that could reach the recipient was never asked, for the whole 7-day outbox lifetime.

Found in the three-host lab run of #539: A sent to C over a direct peer stream, C was then reachable only through B, and minutes later A had 1 pending ACK, 1 queued retry and 0 mesh transmissions.

Change

offer_resend_to_mesh(message, accepted) in send.rs applies the first send's rule to every resend: offer when no carrier took the frame, and when one took it for a recipient can_reach_recipient says it cannot reach. It is called from the four resend branches. A resend over a link that still reaches the recipient is not offered, so an ordinary retransmission costs one copy.

The whole class, path by path:

Path	Before	After
First send refused / swallowed	offered	unchanged
Retry queue, refused	re-queued only	offered
Retry queue, accepted for an unreachable recipient	counted as sent	offered
Outbox flush (flush_outbox_all, flush_outbox_for_peer_via), refused / swallowed	re-queued / counted as sent	offered
ACK timeout	re-queues into the retry queue	covered by the retry loop
Parked-DM probe	offered at park; probe sends ran through the retry loop without an offer	offered at park and on each probe the relay or gateway does not reach

Why re-offering on every resend is safe (same argument as the park path): a neighbour that took the frame refuses further copies of the id for the RelaySeenCache retention window (600 s); the retry backoff bounds how often we ask; each offer spends own-send tokens like any other frame. Excluding neighbours already handed the id would be wrong: a neighbour records an id only when it accepts the frame, and one that refused it (rate limit, full queue) is the one a later offer should reach.

Not handled: a resend into a link that is half-open and not yet detected

While the carrier still lists the recipient as connected, the resend is accepted and can_reach_recipient is true, so nothing is offered. Offering there would not help anyway: offer_to_mesh hands a frame for a recipient who is a neighbour straight to that recipient, over the same suspect link. Routing around a link we still believe is up needs a "suspect link" state, which this PR does not add. The window is bounded by the carrier's own dead-link detection (the Python peer stream sets TCP keepalive 15 s + 3 x 5 s and TCP_USER_TIMEOUT 30 s on Linux), after which resends are refused and this fix carries them.

Tests

Five new cases in crates/offline-protocol/tests/mesh_forwarding.rs:

• a_message_lost_on_a_dead_direct_link_is_carried_by_the_mesh_on_retry: the first frame is swallowed by the direct link, the link dies, the retry goes through B, and A gets message_delivered. Red on main (nothing reaches C).
• a_flushed_message_no_carrier_takes_is_handed_to_the_neighbors
• a_resend_a_carrier_swallows_is_still_handed_to_the_neighbors
• a_flush_a_carrier_swallows_is_still_handed_to_the_neighbors
• a_resend_over_a_live_link_is_not_also_handed_to_the_mesh (cost side: exactly one resend copy, none to B)

Mutations, each turning a test red: removing any one of the four call sites, never offering an accepted resend, and always offering an accepted resend (dropping the reachability check).

Locally: cargo test --workspace --lib (engine lib 2015 tests), cargo test -p offline-protocol (all binaries), cargo clippy --workspace -- -D warnings, cargo fmt --all -- --check, RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps, all clean. No UDL change, no binding regeneration. Core and sealed untouched.

Related

• feat(bindings): an offline-first demo on three devices, and OP_GATEWAY in the image #539: examples/offline-first/run.py stops C before taking it off the shared network, so A sees the stream close. Once this lands that workaround can go: a half-open link now recovers through B on the next retry after the carrier notices.
• feat(protocol): a session forms across the mesh between devices that never met #537 fixes a separate settle bug, where a message that only the mesh carried never got message_delivered. The first test here does not depend on it: the first attempt was accepted, so an ACK was registered and the mesh-carried answer settles it on main.

Docs: docs/state-machines/outbox-and-retries.md, docs/mesh.md (mixed-neighbourhood section), docs/local-api.md, examples/offline-first/, CHANGELOG.md under Unreleased / Fixed.

Rebased onto main now that #537 has merged (a resend the mesh carries settles through its settle_dm_without_pending_ack). The last commit updates what main still said about the gap: docs/local-api.md and the offline-first demo's README and run.py now say a lost message crosses the mesh late (on the first retry after keepalive ends the dead stream), not never; the demo keeps stopping C first so the message lands inside its receive window.

Fixes #541.