fix(diagnostics): stop CEC probe from dumping cores on Pi 5

[vpetersson]

Issues Fixed

Not tied to a tracked issue. On Raspberry Pi 5 (and any board without a usable CEC adapter), the celery container would slowly fill the SD card with core dumps and eventually crash-loop once the disk hit 100%.

Description

The get_display_power celery-beat task (every 5 min) runs the CEC probe as a python -c subprocess (_CEC_QUERY_SCRIPT in src/anthias_server/lib/diagnostics.py). On a Pi 5 there's no usable CEC adapter, so cec.init() succeeds but tv.is_on() raises IOError → the probe reports Unknown. Then, during interpreter teardown, libcec's adapter thread aborts (FATAL: exception not rethrown, SIGABRT), dumping a ~38 MB core every run. The script's try/except can't catch it because it's a C++/pthread teardown abort, not a Python exception.

Fix: once the answer is on stdout, flush() and os._exit(0) to skip the Python/libcec teardown that aborts. Applied to both _CEC_QUERY_SCRIPT and _CEC_SET_SCRIPT. The reported value is unchanged — the probe already has its answer before teardown.

Verified on a live Pi 5: dispatching the task 3× through the worker produces no cores (previously one per run) and still reports Unknown. ruff check/ruff format --check clean; all 36 test_diagnostics.py tests pass.

Checklist

• I have performed a self-review of my own code.
• New and existing unit tests pass locally and on CI with my changes.
• I have done an end-to-end test for Raspberry Pi devices.
• I have tested my changes for x86 devices.
• I added a documentation for the changes I have made (when necessary).

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud