[kvlonge]

Why

The DuckDB E2E (CLI commands) job hung until its 45-minute limit in two runs. Both times the
compile in the audit meta test that must fail on a non-JSON factory meta value never exited; one
or two other commands in the same runs also never finished.

A stack dump from a local reproduction (about 1 in 5,000 runs under load) showed a deadlock in
compute log capture. A late log record from a background thread was written to a capture already
marked complete. The storage built the rejection while still holding its lock, and building it
imports Python, which can release the GIL. The main thread, pruning the logs, then waited for the
lock while holding the GIL, so neither thread could continue.

Changes

• Compute log storage releases its lock before raising the rejection for a write to an inactive
  capture, and documents that no Python may run while the lock is held.
• An integration test forces that exact interleaving (a slow first import of the storage
  exceptions while the main thread prunes). Without the fix it deadlocks every time.
• run_sqb in the E2E helpers gives each command ten minutes. A command still running then has its
  process group sent SIGABRT with PYTHONFAULTHANDLER set, so the failing test shows every
  Python thread's stack and the job continues. Standard input ends at once when a test passes
  none, which matches the /dev/null stdin xdist workers already have. Tests for the helper join
  the CLI shard.

Verification

• New storage test fails (deadlock) before the fix and passes after.
• Focused suites: compute log unit and integration tests, Recall integration tests, the audit
  meta, upstream function and janitor E2E files, and the shared helper tests.
• 4,000 stress runs of the failing compile on the fixed build with no hang.
• make check-ci via the verify hook, ruff, ty, fensu and the public hygiene scan.