feat: Add monitoring functionality to MiniMate protocol and web interface

- Introduced new SUBs for monitoring status, start, and stop commands in protocol.py.
- Implemented read_monitor_status, start_monitoring, and stop_monitoring methods in MiniMateProtocol class.
- Added new API endpoints for monitoring status retrieval and control in server.py.
- Enhanced the web application with a monitoring panel, including battery and memory status display.
- Created a new Python script to parse SUB 0x1C response frames for monitoring status.
- Documented the monitoring status response format and field locations in markdown and text files.

CLAUDE.md

@@ -64,7 +64,7 @@ S3→BW (device replies): [DLE=0x10] [STX=0x02] [stuffed payload+chk] [bare ETX=
   using `DLE+ETX` as inner terminators. The outer parser treats `DLE+ETX` inside a frame
   as literal data — the bare ETX is the ONLY real frame terminator.
 - **Response SUB rule:** `response_SUB = 0xFF - request_SUB`
-  (one known exception: SUB `1C` → response `6E`, not `0xE3`)
+  (no known exceptions — earlier note claiming `1C` → `6E` was WRONG; `1C` → `0xE3` confirmed across 338 frames in 4-8-26 captures)
 - **Two-step read pattern:** every read command is sent twice — probe step (`offset=0x00`,
   get length) then data step (`offset=DATA_LENGTH`, get payload). All data lengths are
   hardcoded constants, not read from the probe response.
@@ -413,10 +413,13 @@ for 0x10 records).
 ## SFM REST API (sfm/server.py)
 
 ```
-GET /device/info?port=COM5                              ← serial
-GET /device/info?host=1.2.3.4&tcp_port=9034            ← cellular
-GET /device/events?host=1.2.3.4&tcp_port=9034&baud=38400
-GET /device/event?host=1.2.3.4&tcp_port=9034&index=0
+GET  /device/info?port=COM5                              ← serial
+GET  /device/info?host=1.2.3.4&tcp_port=9034            ← cellular
+GET  /device/events?host=1.2.3.4&tcp_port=9034&baud=38400
+GET  /device/event?host=1.2.3.4&tcp_port=9034&index=0
+GET  /device/monitor/status?host=1.2.3.4&tcp_port=9034  ← battery, memory, mode
+POST /device/monitor/start?host=1.2.3.4&tcp_port=9034   ← start recording
+POST /device/monitor/stop?host=1.2.3.4&tcp_port=9034    ← stop recording
 ```
 
 Server retries once on `ProtocolError` for TCP connections (handles cold-boot timing).
@@ -570,6 +573,51 @@ a `ComplianceConfig` object is a future task.
 
 ---
 
+## Monitoring commands (SUBs 0x1C, 0x96, 0x97) — confirmed 2026-04-08
+
+All confirmed from 4-8-26/2ndtry BW TX/S3 capture (clean start → 30s monitor → stop cycle).
+
+### SUB 0x1C — Monitor status read
+
+Standard two-step read (probe at offset 0x00, data at offset 0x2C).
+Response SUB = 0xFF − 0x1C = **0xE3** (standard formula — no exception).
+
+Payload length indicates mode:
+- **44 bytes (0x2C)** — unit is **idle**: full status block with battery + memory
+- **12 bytes** — unit is **monitoring**: abbreviated block, no battery/memory fields
+
+**Field offsets (idle payload, relative to the 11-byte section header start):**
+
+| Offset | Field | Type | Notes |
+|---|---|---|---|
+| `[0x2F:0x31]` | battery voltage × 100 | uint16 BE | `0x02A8` = 680 → 6.80 V |
+| `[0x31:0x35]` | memory total (bytes) | uint32 BE | e.g. 983040 = 960 KB |
+| `[0x35:0x39]` | memory free (bytes) | uint32 BE | |
+
+### SUB 0x96 — Start monitoring
+
+Single write frame, **no data payload** (empty body).
+Response SUB = 0xFF − 0x96 = **0x69**.
+
+Wire bytes (confirmed frame 92 of 2ndtry BW capture):
+```
+41 02 10 10 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 a6 03
+```
+
+### SUB 0x97 — Stop monitoring
+
+Single write frame, **no data payload** (empty body).
+Response SUB = 0xFF − 0x97 = **0x68**.
+
+Wire bytes (confirmed frame 305 of 2ndtry BW capture):
+```
+41 02 10 10 00 97 00 00 00 00 00 00 00 00 00 00 00 00 00 a7 03
+```
+
+Both start and stop acks are standard 17-byte zero-data S3 frames.
+
+---
+
 ## What's next
 
 - Compliance config encoder — build raw write payloads from a `ComplianceConfig` object