The send path fetches full bundles only when a device needs a session
established, so it does not drain one-time prekeys on every message. The
contact's address rides with those bundles -- so every later send had no
address, computed the `local:` key-log subject instead of `fnid:`, matched
no leaf, and refused its own send. flamenet-relay!82 puts the address on
the directory; this reads it.
Two bugs the wiring exposed:
* `rememberFnid` silently overwrote a DIFFERENT address, the one thing
its own doc comment says it must never do. An fnid is derived from the
account key, so a new address is a different account, not a new device.
It went unnoticed while only the once-per-conversation bundle path fed
it; the directory feeds it every send. It marks CHANGED now.
* `guardIdentity` read the pinned address and passed it back into the
comparison against itself, so "a different address is a different
person" could never fire on a send. It compares the served one now.
And the copy: only `IdentityChangedException` was named, so
`KeyNotLoggedException` and `KeyLogForkException` reached the screen as
"Something went wrong reaching that server." -- sending a person to check
their signal for a decision this phone had made.
Also: the call screen painted a flat `colorScheme.background` rectangle
over the app's gradient, which read as a blue box around the call area.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
