App 2.41.0, server 2.9.0: recordings reach the server

A finished signal recording goes to an outbox and is sent gzipped with
the car's token (PUT /v1/logs/{name}); the service retries every 2
minutes while the car is offline. The server keeps the newest 200 on a
new volume (LOGS_DIR); reading takes a token of its own (LOGS_TOKEN).
fetch-logs in the dev shell fetches new ones into logs/.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LhzAVaUyqcw5PkGjz4mWW6

SPECS.md

@@ -140,6 +140,25 @@ tyre pressures, GPS (lat, lon, elevation, heading) and the is_* flags. It does *
   confirmed car facts, app structure, UI conventions, build/test/ship, documents. It replaces
   upstream's EVABRPUploader text. The test emulator is now in the flake: `nix run .#car-emulator`
   (Android 9 AOSP at 1920×720, 160 dpi; the car build installs as the system user — checked).
+- 2026-10-27 — App 2.41.0, server 2.9.0: **recordings reach the server** (owner: "can we make
+  it so that we can upload the logs to an endpoint in the server, and you can get the logs from
+  there? that way i don't have to carry a usb stick"). A finished signal recording goes to
+  `files/log-outbox` (`LogOutbox`, at most 10 waiting) and is sent at once, gzipped, with the car's
+  token: `PUT /v1/logs/{name}`. Offline, 401 (not paired yet), 404 (a server without logs), 408,
+  429 or 5xx keep it, and the service's tick sends it again, at most every 2 minutes; any other
+  refusal drops it. The Logs tab says "Sent to the server." or how many wait and why. Server
+  (`logs.go`): `LOGS_DIR` on a new 1Gi volume `mg4-server-logs`, the newest 200 files and none
+  older than 180 days, names as the app's only, up to 2 MB sent and 8 MB unpacked, UTF-8 only; the
+  same name replaces itself. Reading (`GET /v1/logs`, `GET /v1/logs/{name}`) takes `LOGS_TOKEN`, a
+  new optional Secret value that must differ from `INGEST_TOKEN`; the car's token cannot read, the
+  read token cannot write. `fetch-logs` in the dev shell fetches the new ones into `logs/`
+  (gitignored, as are the recordings copied into the checkout's top folder), token from
+  `~/.config/nilsmg4/logs-token`. Tested: server unit tests (both tokens, refusals, pruning,
+  config); the real server code in a harness on this machine took the 08:52 recording gzipped as
+  the app sends it (204), refused the car's token for reading (401), and `fetch-logs` brought it
+  back byte for byte, once. The app's own sending could not be pointed at that harness (the app
+  takes https only); on the emulator the recording lands in the outbox and the Logs tab says it
+  waits. Not tried on the car.
 - 2026-10-27 — App 2.40.4 published (`car-2.40.4`).
 - 2026-10-27 — App 2.40.4: **the recorder's listening works on Android 9**. Both recordings
   from the car (08:49 and 08:52, 2.40.3) said "listening to the assistance properties: not