feat: camera control — read and adjust dashcam settings over Wi-Fi

[droomurray]

Camera control — read and adjust dashcam settings over Wi-Fi

Adds a Camera tab and /api/camera/* endpoints to read the dashcam's current settings and safely change them over the undocumented Novatek netapp HTTP interface.

What it does — reads settings (cmd=3014) decoded against a derived per-model command map; allow-listed writes validated against the camera's option list and read back to verify; on/off toggles + drop-downs + a recording pill; settings the camera refuses are read-only with a reason (resolution over Wi-Fi, exposure, lenses not attached), and lens-dependent ones re-enable automatically when the lens is connected.

Safety — hard denylist of destructive ids (format/factory-reset/firmware/delete/reboot/restart-wifi/SSD), refused before any request is built and never shown; gentle single-request transport; auto pause/resume recording for record-gated settings.

Data — command_map.json reformats only the factual API data (ids, keys, option enums) from the VIOFO app's device-cmd-manager.db; the .db itself is not redistributed (scripts/build_command_map.py regenerates it). All 29 app models mapped; A329S validated on hardware, others untested.

Tests — tests/test_control.py, 11 offline unit tests.

[droomurray]

This PR adds a Camera tab and /api/camera/* endpoints to read and adjust the dashcam's own settings over Wi-Fi (parking mode, watermarks, HDR, LEDs, GPS, loop length, bitrate, etc.), alongside the existing sync/browse/export features.

How it was built — I wanted the mapping to be grounded rather than guessed, so it came together in three stages:

1. Firmware analysis. I statically analysed the A329S firmware (the cardv binary on the Novatek NA51102) to confirm the undocumented netapp HTTP grammar — http://<cam>/?custom=1&cmd=<id>&par=<value> with XML replies, the cmd=3014 settings dump, and the rough command-id ranges. That gave the protocol shape but not what each id means.
2. App decompilation. To get real semantics I decompiled the official VIOFO Android app (apkeep → jadx) and found it ships a SQLite asset (device-cmd-manager.db) mapping every command id to a key, description, and option enumeration, per camera model. I reformatted just that factual API data into command_map.json — the app's .db itself is NOT redistributed, and scripts/build_command_map.py regenerates it.
3. Automated testing against a real camera. I wrote a harness that drives the actual web API and round-trips every setting against my A329S — read current value, write a different valid value, confirm it applied by re-reading the camera's live config, then restore the original — exporting the full settings dump before and after to prove nothing was left changed. That empirical pass is where the safety behaviour came from: it's how I found that some "reads" are actually destructive actions (a bare cmd=3010 is format SD, and 3013 wedges the daemon), which settings are silently rejected while recording (so the layer briefly stops/restarts recording for those), and which simply can't be set over Wi-Fi (resolution) or need a lens that isn't attached.

Safeguards that came out of it:

• Destructive commands (format, factory reset, firmware update, delete, reboot, restart-Wi-Fi, SSD format/delete) are on a hard denylist — refused before any request is built and never shown in the UI. Writes are allow-listed to enumerated settings, validated against the camera's option list, and read back to verify. One request at a time so it won't overrun the camera's single-threaded daemon.
• Honest about limits. Settings the camera won't change over Wi-Fi (resolution, exposure) or that need an unattached lens are shown read-only with the reason; the lens-dependent ones re-enable automatically when the rear/interior camera is connected.
• Tests + docs. Offline unit tests for the denylist/validation/verify logic, plus a README section.

One thing I'd flag for your call: the derived command map is reformatted from VIOFO's app data — if you'd rather handle it differently, I'm happy to change it. And it's only been validated against my A329S; other models are mapped but untested.

Heads up on CI: the initial run tripped on a ruff import-order nit in the test file — I've fixed that (ruff check is clean and the tests pass), so it just needs your approval to re-run the workflow.

No pressure at all to merge — your project, your call. Happy to adjust anything (squash, trim the data file, rework the UI to match your conventions, whatever helps).