fix(mesh): route Meshtastic public-channel text to the channel thread, not DMs

Inbound Meshtastic text addressed to BROADCAST_NUM (the default public
LongFast channel, or any channel slot) was filed into a per-sender 1:1 DM
thread, so public-channel messages polluted individual people's DM chats
and appeared as if sent directly to the user.

packet_to_inbound_frame now detects `to == BROADCAST_NUM` and emits a new
synthetic RESP_MESHTASTIC_CHANNEL_TEXT frame
([channel_idx][sender_prefix(6)][text]) that the listener files under the
channel thread (contact_id = u32::MAX - idx) while still attributing the
message to its real sender. Directed text (to == our node) still routes to
the DM thread — a regression test locks that split in.

send_channel_text now sets MeshPacket.channel (field 3) so archy actually
transmits on channel 0 (public) instead of ignoring the slot. Mesh.vue keeps
the synthetic "Meshtastic !xxxx" sender id when that is the best identity
available for a stock public-channel device.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/SESSION-1.8.0-OTA-PROGRESS.md

@@ -10,12 +10,35 @@ Updated: 2026-06-30
 identical in off-grid and normal mode. Test bed = `.116` / `.198` / `.228` (all EU_868).
 Don't touch the federation/FIPS path.
 
-### TL;DR of where we are
-The **archy software is correct and deployed.** The blocker is now PROVEN to be at the
+### ✅✅✅ SOLVED 2026-06-30 — archy↔archy LoRa WORKS (delivery + E2E pill + identity)
+VERIFIED: `.198→.228` directed DM → `.228` row `RECEIVED enc=True peer="Arch Optiplex"`.
+All three nodes (.116/.198/.228) now hear each other + stock peer 3ccc. Deployed binary
+**`737b16c3235b`** active on all three. Fix source **COMMITTED as `a57ae388`** on `main`
+(not yet pushed to gitea-vps2/origin).
+
+**THE fix (receive stream):** archy ignored `FromRadio.rebooted` (field 8). Every config
+write reboots the radio → firmware PhoneAPI resets to `STATE_SEND_NOTHING` and stops
+streaming received packets until the client re-sends `want_config`. archy never did →
+went deaf to inbound (that's why old messages only arrived after a full restart = fresh
+want_config). Fix: handle `FROM_RADIO_REBOOTED` → set `pending_reinit` → re-send
+want_config; plus a 10s keepalive heartbeat (insurance vs 15-min idle serial close) and
+a pinned `modem_preset=LONG_FAST` so all radios share frequency. Combined with the earlier
+E2E send fix (plain TEXT_MESSAGE_APP DM, firmware PKC) this closes archy↔archy LoRa.
+
+**Open follow-ups:** #A surface received msgs under archy identity in all UI views; #6
+device-onboarding modal; #8 Device-tab settings panel; #7 re-verify .116 in rotation;
+#12 make modem_preset authoritative + hot-swap re-binding + RX-stall watchdog;
+#14 signal-strength (RSSI/SNR) indicator per contact (from MeshPacket rx_rssi/rx_snr);
+#15 map view plotting peer locations where shared (Meshtastic POSITION_APP portnum=3
+lat/lon). See the resume memory `project_session_resume_2026_06_30_lora.md` for the full
+task list.
+
+### (historical) earlier TL;DR — RF-layer suspicion, now RESOLVED by the reboot-recovery fix
+The **archy software is correct and deployed.** The blocker was at the
 **radio/RF layer: the three radios are not hearing each other over the air at all.** No
 amount of archy code change will fix that until the radios actually RF-link. **Resume by
 testing the radios directly at home (Meshtastic phone app over Bluetooth) — see "DO THIS
-FIRST AT HOME" below.**
+FIRST AT HOME" below.** ← this turned out to be the want_config resubscribe bug above.
 
 ### What is DONE and deployed (commit pending — see below)
 - **E2E send fix** (`core/archipelago/src/mesh/mod.rs` `send_message`, ~L1542): archy↔archy