Fix UPER encoding of CurvatureCalculationMode; verified on hardware

CurvatureCalculationMode is the one extensible ENUMERATED in CAM:
  ENUMERATED {yawRateUsed(0), yawRateNotUsed(1), unavailable(2), ...}
UPER encodes an extensible ENUMERATED as an extension bit followed by the root
index - 1 + 2 = 3 bits. All three of our encoders wrote only the 2-bit index,
shifting yawRate and the entire low-frequency container one bit early for any
standards-compliant receiver.

It went unnoticed because every end of this project shared the mistake: the
Kotlin codec was ported bit-for-bit from cam.c, so phone and ESP32 agreed
perfectly with each other and with nothing else. Confirmed against the ETSI
ASN.1 in the C-ITS-Parser checkout, where rasn marks this type - and only this
type - #[non_exhaustive].

Fixed in all three copies of the encoder (app CamUperCodec.kt,
obu-firmware/main/cam.c, obu-cam-transmistter/main/cam.c) plus the decoder,
which now rejects rather than misreads a set extension bit. Frame size is
unchanged at 43 bytes. Transmitter reflashed and the phone decodes its CAMs.

Also in this change:

- serial_link: skip send_frame entirely when no USB host is attached, and raise
  the tx mutex timeout above the worst-case hold. With the phone unplugged every
  write blocked its full timeout while holding the lock, so forwarded CAM_RX
  traffic starved the 1 Hz heartbeat - observed as "tx mutex timeout, dropping
  frame" on the console, and it would have tripped the phone's link watchdog.
  Verified gone on hardware.
- Log decoded and failed CAMs in CamUseCaseRepository. "The app shows nothing"
  had two indistinguishable causes; a silent `?: return` made this bug much
  harder to find than it needed to be.
- Remove the ESP32 send-only/send-and-receive toggle. Reception can't be
  disabled in firmware (raw TX only works while promiscuous), so it was an
  app-side filter pretending to be a radio control.
- V2X monitor follows the serial link state on the ESP32 path instead of MQTT,
  which is permanently disconnected there; CAM intake is gated on the link being
  up, and engine state is cleared when it drops.
- About screen: 0.5.0, Phase 03.
- Track obu-cam-transmistter, the bench CAM transmitter. Its cam.c is compiled
  (unlike obu-firmware's reference copy) and must stay bit-identical to the other
  two - this commit is what that coupling costs when it's broken.
- Document the two-toolchain split: this project builds on IDF 5.5.4, obu-firmware
  on the pinned 6.1. Exporting both in one shell fails confusingly.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

obu-firmware/main/cam.c

@@ -1,3 +1,8 @@
+// NOT COMPILED - deliberately absent from main/CMakeLists.txt's SRCS. This firmware no longer
+// encodes CAM at all: the phone builds and UPER-encodes it and sends the bytes down serial_link,
+// and this side only GeoNetworking-wraps opaque payloads. The file is kept as the byte-exact
+// reference the Kotlin encoder (app CamUperCodec.kt) was ported from, so fixes must be applied
+// here too or the next person porting from it reintroduces the bug.
 #include "cam.h"
 #include <string.h>
 
@@ -108,8 +113,14 @@ int cam_encode(const cam_fields_t *f, uint8_t *buf, size_t buf_len)
     //            CurvatureConfidence ENUM 8 values -> 3 bits
     bw_put_bits(&bw, 1023 - (uint32_t)(-1023), 11); // curvatureValue: unavailable(1023)
     bw_put_bits(&bw, 7, 3);                         // curvatureConfidence: unavailable(7)
-    // CurvatureCalculationMode ENUM {yawRateUsed,yawRateNotUsed,unavailable} -> 2 bits
-    bw_put_bits(&bw, 2, 2);                 // unavailable
+    // CurvatureCalculationMode ENUM {yawRateUsed,yawRateNotUsed,unavailable, ...} - note the
+    // extension marker: UPER encodes an extensible ENUMERATED as an extension bit followed by
+    // the root-list index, so this is 1 + 2 = 3 bits, NOT 2. This file previously wrote only the
+    // 2-bit index, which shifted yawRate and the entire low-frequency container one bit early for
+    // any standards-compliant receiver. Harmless between this project's own encoder and decoder
+    // (both had the same error); wrong against every third-party station.
+    bw_put_bits(&bw, 0, 1);                 // extension bit: value is in the root list
+    bw_put_bits(&bw, 2, 2);                 // unavailable(2)
     // YawRate: YawRateValue(-32766..32767)->16 (offset from -32766),
     //          YawRateConfidence ENUM 8 values -> 3 bits
     bw_put_bits(&bw, 32767 - (uint32_t)(-32766), 16); // yawRateValue: unavailable(32767)

obu-firmware/main/serial_link.c

@@ -72,7 +72,18 @@ static bool send_frame(uint8_t type, const uint8_t *payload, int len)
     // so the shared buffer (and the four-part write) can't interleave between callers.
     static uint8_t s_crc_buf[3 + SERIAL_LINK_MAX_PAYLOAD];
 
-    if (s_tx_mutex && xSemaphoreTake(s_tx_mutex, pdMS_TO_TICKS(200)) != pdTRUE) {
+    // No host on the other end: the TX buffer never drains, so every write below would block its
+    // full timeout and this frame is going nowhere regardless. Bail before taking the mutex -
+    // otherwise a burst of promiscuously-captured CAMs holds the lock for hundreds of ms each and
+    // starves the heartbeat, which is exactly what "tx mutex timeout, dropping frame" was.
+    if (!usb_serial_jtag_is_connected()) {
+        return false;
+    }
+
+    // Timeout must exceed the worst-case hold below (4 writes x SERIAL_LINK_WRITE_TIMEOUT_MS),
+    // or a legitimately slow-but-working host makes contending senders drop frames instead of
+    // waiting their turn.
+    if (s_tx_mutex && xSemaphoreTake(s_tx_mutex, pdMS_TO_TICKS(SERIAL_LINK_TX_LOCK_TIMEOUT_MS)) != pdTRUE) {
         ESP_LOGW(TAG, "send_frame: tx mutex timeout, dropping frame");
         return false;
     }
@@ -87,9 +98,9 @@ static bool send_frame(uint8_t type, const uint8_t *payload, int len)
     // Four separate writes rather than one assembled buffer - simplest given payload is
     // already wherever the caller has it (avoids a second copy of up to 160 bytes).
     // usb_serial_jtag_write_bytes() blocks up to the given tick timeout if the host isn't
-    // reading fast enough; 100ms is generous for a ~160-byte frame at USB full-speed and keeps
-    // a wedged/disconnected host from hanging the radio TX/RX tasks indefinitely.
-    const TickType_t write_timeout = pdMS_TO_TICKS(100);
+    // reading fast enough; generous for a single frame at USB full-speed, and keeps a wedged
+    // host from hanging the radio TX/RX tasks indefinitely.
+    const TickType_t write_timeout = pdMS_TO_TICKS(SERIAL_LINK_WRITE_TIMEOUT_MS);
     int wrote = 0;
     wrote += usb_serial_jtag_write_bytes(sync, sizeof(sync), write_timeout);
     wrote += usb_serial_jtag_write_bytes(head, sizeof(head), write_timeout);

obu-firmware/main/serial_link.h

@@ -51,6 +51,13 @@
 // to SERIAL_LINK_MAX_PAYLOAD below.
 #define SERIAL_LINK_USB_BUF_SIZE  1024
 
+// Per-write block ceiling, and the mutex acquire timeout that must comfortably exceed the
+// worst case of one frame (4 writes: sync, head, payload, crc). Keep that relationship if you
+// change either number - a lock timeout below the max hold turns normal contention into
+// dropped frames, which is how the heartbeat was being starved by forwarded CAM_RX traffic.
+#define SERIAL_LINK_WRITE_TIMEOUT_MS   100
+#define SERIAL_LINK_TX_LOCK_TIMEOUT_MS 600
+
 // Max CAM payload this link will carry. MUST match SERIAL_LINK_MAX_PAYLOAD in the app's
 // SerialFrame.kt - a mismatch means every frame above the smaller of the two is rejected by that
 // side's "length exceeds max, resync" branch, silently.