CMD_SYNC_NEXT_MESSAGE drains a shared queue, so a host that only advances
its polling loop on packet types it recognizes stalls on the first unknown
one, and everything queued behind it stays undelivered until the next
PACKET_MESSAGES_WAITING. This already bit clients when
PACKET_CHANNEL_DATA_RECV (0x1B) was introduced; spelling it out so the
next added type doesn't repeat it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds RESP_CODE_CONTACT_MSG_SENT_V3 (0x1E) and
RESP_CODE_CHANNEL_MSG_SENT_V3 (0x1F) so firmware that sends messages on
its own (bot auto-replies, on-device keyboard input) can mirror them into
the companion app's history, which today only ever sees inbound traffic
and messages the app itself sent. See #3225.
Both ride the existing offline-queue / MSG_WAITING / SYNC_NEXT_MESSAGE
pipe and reuse the RECV_V3 byte layout, with the pubkey field holding the
recipient instead of the sender and the SNR byte reserved. Requires
app_target_ver >= 3; there is no pre-V3 shape, so older apps are skipped.
Mainline never calls these -- nothing in companion_radio self-originates
messages -- so this is API surface for custom builds, and the linker
drops both functions when unused (identical flash usage before/after).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
JakubandClaude Opus 5