fix(ci): run GUI test under pyqt5 instead of skipping

[hongquanli]

Summary

tests/control/test_HighContentScreeningGui.py has been --ignore'd in CI since #391 with the note "PySide6 QObject double-init bug". This PR stops skipping it:

• Set QT_API: pyqt5 and PYTEST_QT_API: pyqt5 as job-level env in main.yml, forcing qtpy/pytest-qt onto PyQt5 (the known-good local recipe).
• Drop the --ignore from the pytest invocation.

setup_22.04.sh already installs PyQt5 via apt (python3-pyqt5), so no dependency changes are needed.

Verification

• Locally headless under the pin (pristine configurations/configuration_Squid+.ini, same file CI copies): 5 passed in 17.9s.
• CI on this PR is the authoritative check — it runs the full suite including the previously-skipped file under Xvfb.

Open question (documented, not fixed here)

The PySide6 QObject double-init failure itself is unchanged: under PySide6, GUI construction in the test fails (qtpy picks PySide6 when it's importable). Pinning CI to PyQt5 matches the production launch path (main_hcs.py and run_acquisition.py both set QT_API=pyqt5), so this is an acceptable steady state; root-causing the PySide6 path (likely the QtMultiPointController(MultiPointController, QObject) multiple-inheritance init pattern) remains a separate issue if PySide6 support is ever wanted.

🤖 Generated with Claude Code

[hongquanli]

CI finding + fix (second commit): the first run proved the pyqt5 pin works — test_HighContentScreeningGui.py passed (5/5) in CI — but the job then segfaulted at test_channel_sequence.py:116 (qtbot.waitUntil, exit 139). Reproduced deterministically on macOS with just the two files in one process: the full-application GUI test leaves Qt/thread state behind (faulthandler dump shows the simulated-camera stream thread and slack-notifier worker still alive) that crashes a later Qt event loop.

Fix: keep the main pytest run ignoring the GUI test and run it as its own pytest invocation in a second step — it is now enforced in CI, just process-isolated.

This also resolves the original mystery: with no env pin, pytest-qt picked PySide6 for qtbot while the app code (qtpy) preferred PyQt5 — the "QObject double-init" was a mixed-bindings artifact, not a PySide6 port bug per se. Follow-up candidates (separate issues): teardown of the GUI test's background threads, and a real PySide6 compatibility pass if ever desired.

[hongquanli]

Second CI finding: the job-level pin had a wider blast radius than intended — the main run (still --ignoreing the GUI test, i.e. exactly master's suite) passed all 1413 tests and then segfaulted at interpreter shutdown. The pin flips binding selection for every Qt test's teardown, hitting PyQt5's destructor-order-vs-GC conflict at exit (the documented reason main_hcs.py exits via os._exit()). Master runs this suite unpinned and green.

Pushed 0d3be569: the main run is now byte-identical to master's invocation, and the QT_API/PYTEST_QT_API=pyqt5 pin is scoped to the isolated GUI-test step only — the one invocation that needs it (and which passed 5/5 in CI under the pin in the first run).

[hongquanli]

Third CI finding + fix (9de2f061): with the step-scoped pin, the main suite passed and the isolated GUI-test step passed 5/5 — but that process still segfaulted during interpreter shutdown (after the green summary). Under PyQt5, a process that constructed the full HCS GUI crashes in Qt C++ destructors at exit even when every test passed — the exact crash main_hcs.py avoids with os._exit().

Fix mirrors the product's own solution: an env-gated (SQUID_PYTEST_HARD_EXIT=1) pytest_unconfigure hook that flushes output and os._exit()s with pytest's real exit status, set only on the isolated CI step. Verified locally: summary still prints, pass → exit 0, failure → exit 1.

[hongquanli]

Round-4 CI failure root-caused — it's a pre-existing master flake, and this PR now fixes it (649c0b8a).

The failing run was the main pytest step — byte-identical invocation to master's (--ignore on the GUI test, no Qt pin) — passing all 1413 tests and then segfaulting at interpreter shutdown. Master itself fails exactly this way in 3 of its last 15 runs (28883871972 on 24276973, 28762269294 on 780d80e3, 28559414408 on 5faaad47): N passed → Segmentation fault (core dumped) → exit 139. This also retroactively explains round 2 here, which I misattributed to the job-level Qt pin.

Fix: set SQUID_PYTEST_HARD_EXIT=1 on the main step too. The hook runs after the session completes and all reporting (junit/terminal/coverage) is written, and exits with pytest's real status — real failures still fail the step; only the post-green Qt-teardown crash is neutralized. Net effect for the repo: a ~20% CI flake on master goes away.