Pipeline post-download work off the cycle's critical path

[jusii]

Summary

Authored this to mitigate long inter-file dead time during sync — Wi-Fi saturated at N=1 download, but the worker spent N seconds per file on GPS extract + dashcam delete + mark_done after the download finished, during which the next file's bytes weren't flowing. Moving that tail to its own single-thread executor lets the next download start immediately.

During empirical testing on an A329 I realised the actual dominant culprit on my deployment was something else entirely: the SQLite state DB lives at ${RECORDINGS}/.viofosync.db, and with a NAS-backed recordings volume the per-file DB writes hit ~30 s lock-acquisition stalls (SQLite fcntl() over NFS waiting on busy_timeout=30000 while NFS write-back flushes the freshly-downloaded MP4). That's a separate architectural issue I'll look at next.

But this pipelining change still feels like an improvement on its own — worth ~6 s per file on cleaner setups, and it's a no-op when the new PIPELINE_POST_DOWNLOAD setting is off — so making the PR anyway.

What's in

• New PIPELINE_POST_DOWNLOAD setting (default on). When on, the tail stage runs on a dedicated ThreadPoolExecutor(max_workers=1, name=viofo-tail) while the main worker picks up the next pending file.
• Toggle off restores the legacy inline behaviour, useful for A/B.
• Per-stage timing columns on download_queue (download_started_at, download_finished_at, tail_submitted_at, tail_finished_at) for attributing cycle wall-clock. Idempotent ALTERs.
• Per-cycle log line: cycle done: drained=N duration=Ts pipeline=<bool>.
• DEBUG-level per-step logs in the tail for ad-hoc inspection.
• 4 new tests pinning the executor thread name, inline fallback, end-of-cycle tail draining, and timing column population.

Test plan

• pytest — full suite passes (147 + 4 new).
• Deployed image against an A329 over Wi-Fi; observed downloads continuing at full rate while the previous file's GPS extract runs in the background. Tail logs show GPS extract on the viofo-tail thread when pipelining is on.
• Toggled PIPELINE_POST_DOWNLOAD=false, confirmed legacy sequential behaviour preserved.

[RobXYZ]

Thanks for this. Agree in principle but I'll read through the changes before merging.

Regarding viofosync.db in the recordings on an NFS share - perhaps it makes more sense to be in /config

[jusii]

And just testing the sqlite theory, seems to be it atleast on my setup. Symlinked sqlite db from recordings dir which is in nfs to local filesystem, and that solved the stalling I was experiencing. So moving it to config dir would solve this.

But anyhow, pipelining them wont hurt and we get little quicker all files downloaded so lower risk Viofo station mode turning off mid download.