`poll` was at 0%. The tests that cover it — the Live* suites — are opt-in
via FN_LIVE_FLEET and skip in an ordinary run, so the single most
important path in the client contributed nothing to a normal build. That
is worse than having no test, because the file listing says otherwise.
Nothing here is stubbed below the transport: the peer is a real
DeviceIdentity, the envelopes are real ciphertext from a real ratchet, and
only the relay's HTTP is a mock. A decrypt that succeeds here succeeded
for the same reason it does in the field.
The three-chain rule gets the test its comment asks for. This used to be
`existingSession(fromDevice) ?: respond(...)`, which reads as a fallback
and is not one: with a stored session it was the only thing tried, decrypt
threw for a peer on a different chain, and the catch swallowed it. That
happens whenever both sides run X3DH before either has processed the
other's prekey — two people opening the same chat at once, which is
ordinary — so the test stores one chain and then has the peer start a
fresh one.
The C1 receive-side gate is asserted from both sides: a handshake offering
an unpinned key while claiming a pinned contact is dropped, and the same
handshake from the pinned key is accepted. Without the gate, anyone could
hand us a session with their own key and every later message would render
as that contact.
Also that one unreadable envelope does not discard the rest of the page
AND that the watermark still passes it, or a single corrupt message is
retried for ever and the inbox never drains; and that a failed poll
surfaces rather than being reported as an empty inbox, since "no new
messages" and "we could not ask" are different states.
⚠️ One test needed two distinct user ids: two identities claiming one user
is exactly what C1 refuses, so writing it with the default sender makes
the second message vanish — correctly, and confusingly.
Conversations 25.4% -> 43.0%, client 63.2% -> 68.9% lines.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
