fix(recorder): survive SQLite writer contention in the video writer

[abrichr]

What broke

The video_writer child process exited 1 during startup on hosted Windows, and the recorder reported only this:

ERROR ... _wait_for_tasks_started:593 - Recording tasks exited before readiness: ['video_writer']
RuntimeError: Recording child process failed: mem_writer (exit code -15), screen_event_writer (exit code -15), video_writer (exit code 1)

Digging the child's traceback out of the captured stderr of run 33186627127 gives the actual cause:

File ".../openadapt_capture/recorder.py", line 1272, in video_pre_callback
  crud.update_video_start_time(db, recording, video_start_timestamp)
File ".../openadapt_capture/db/crud.py", line 352, in update_video_start_time
  session.commit()
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) database is locked
[SQL: UPDATE recording SET video_start_time=? WHERE recording.id = ?]

The video writer is the last writer a recording starts, and persisting the video start time is the first thing it does. By then the screen, action, performance and memory writers are all committing to the same per-capture SQLite file, and they share one write lock. Every other writer waits and retries for it (#106). This statement did not. It took the connection's five-second wait, and an expiry raised straight out of the startup callback and killed the process.

Nothing about the wheel, the drive letter, or the resolved dependency versions is involved. It is contention, and it shows up on hosted Windows because that runner is slow enough to lose the race.

What changed

The fix. The insert retry becomes one write-transaction helper, and the video start time update goes through it. It is now a single UPDATE reporting a missing row by affected row count, rather than a read into a session the retry would have to unwind. Each attempt logs how long it waited, since that wait is the only measure of how close a capture came to losing the race.

Diagnostics. WrapStdout writes a child's formatted traceback to a synchronous queue before the child exits. The readiness wait logs it, and _raise_for_failed_processes attaches it to the error it raises. The next Windows-only startup failure reads from the parent's log without anyone reconstructing it from captured stderr.

Orphan cleanup. record() force-stops surviving children and releases its queues in a finally, and Recorder does the same after joining, in case record() raised first. Both failing runs sat until the 35-minute job timeout after the assertion had already failed: a live child keeps the inherited stdout open, and multiprocessing joins live children at interpreter exit with no timeout, so one leaked writer hangs the program that ran the recording. A queue feeder thread whose reader has died blocks the same way.

Evidence

The qualification lane reproduces this only under load. Dispatched back to back on a quiet runner, it went green on both the fixed branch (33192963705) and unfixed main (33192946319), with zero lock warnings in either. So the green run is necessary but not sufficient, and the contract is pinned where it is deterministic instead.

test_the_real_video_writer_starts_through_a_writer_lock drives the production write_events body with the production video_pre_callback against a database whose write lock another connection holds. Against the code before this PR it fails with the video writer never announced readiness, which is the symptom the recorder reported in runs 33186627127 and 33189604580. It passes here. Encoding a frame would need a real FFmpeg process, so it supplies a preflighted provision and stops at the startup callback, which is where the writer died.

Three more tests cover the retry and fail-loud behaviour of the update, and six cover the child traceback, the reaping, and the queue release.

The lane

hosted-live-recorder-windows returns from live-qualification.yml to the required matrix in production-qualification.yml, and check_release_ci.py requires Hosted live recorder qualification (windows-latest) again. The two files are back to their state before #115, except the twelve-minute bound on the trial step, which stays.

One caveat worth stating: because the lane never went red on a quiet runner, its return to the gate rests on the deterministic test, not on a red-to-green CI transition. If a different contention shows up later, the new wait timings and child tracebacks will name it instead of leaving an exit code.