feat: RTC rebrand + on-chip Meshtastic decode + acid display

- Rebrand to RTC (Reticulum / meshTastic / meshCore); Meshtastic row = T.
- On-chip Meshtastic decode (mbedtls AES-128-CTR + protobuf) surfacing text
  and node short-names, mirroring firmware/tools/meshtastic_decode.py.
- Device identity 'Reticutasticore' / 'RTC' (DEVICE_NAME) baked in for all
  three networks; boot splash shows it.
- Trippy OLED: acid smiley with a periodic spinning-striped freak-out
  (googly eyes + gaping mouth), punk 'bubble' RTC header, three live network
  rows (counts + RX blips), last-decoded line.
- Hardware-confirmed: Meshtastic + MeshCore both received (0x12 MeshCore
  sync word guess validated); Reticulum still placeholder.

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

firmware/README.md

@@ -5,20 +5,30 @@ Embedded firmware for the single-device **3-in-1**: one Heltec WiFi LoRa 32 V3
 Meshtastic / MeshCore / Reticulum PHY configs. See `../docs/ARCHITECTURE.md`
 §2-§3 for why Phase 1 is a time-multiplexed single radio (Option A).
 
-## Current increment: tri-protocol RX scanner
+## Current increment: RTC scanner + acid display + Meshtastic decode
 
-`src/main.cpp` is the **first** Phase 1 step. It does not bridge, decode, or
-transmit yet — it rotates the SX1262 through each network's PHY preset, listens
-for a fixed dwell window, and logs every raw LoRa packet it demodulates
-(length, RSSI, SNR, hex). The point is to answer the project's central open
-question before building any protocol stacks: *can one re-tuned radio actually
-hear all three networks?*
+`src/main.cpp` rotates the single SX1262 through each network's PHY preset
+(**R**eticulum / mesh**T**astic / mesh**C**ore = **RTC**), listens per dwell
+window, logs every raw packet, and **decodes Meshtastic on-chip** (AES-128-CTR
+via mbedtls + protobuf → text / node names). The 128×64 OLED shows an animated
+acid-house UI: a smiley (that periodically freaks out — spins, stripes, eyes +
+mouth open), a punk `RTC` header, three live network rows (packet counts + RX
+blips), and the last decoded event.
 
-**Validated on hardware (2026-07-01):** flashed to a Heltec V3, the scanner
-`radio.begin()`'d cleanly, cycled all three presets, and received **live
-Meshtastic broadcast packets** (payloads prefixed `ffffffff`) at −36 to
-−41 dBm during the Meshtastic dwell. The single-radio time-multiplex premise
-holds. MeshCore/Reticulum windows were silent — expected, see open items below.
+Device identity `Reticutasticore` / `RTC` is baked in (`DEVICE_NAME`) as the
+name this device will present on all three networks once the TX/participation
+layer lands — so a message addressed to it will be routable.
+
+**Validated on hardware (2026-07-01):**
+- radio inits clean, all three presets cycle, display renders.
+- **Meshtastic**: live broadcast packets at −34 to −44 dBm; on-chip decode
+  matches the offline reference (`tools/meshtastic_decode.py`, verified against
+  real captures — decoded node "Arch Optiplex"/"ARCH").
+- **MeshCore**: received real packets too — so the `0x12` sync-word guess is
+  **correct** (was an open item).
+- **Reticulum**: silent — placeholder PHY config + likely no RNode nodes near.
+
+Still RX-only: no bridging or transmit yet.
 
 ## Open items baked into the config table