CI-15: test_safety87.py joins the serial group (real-clock meter freshness)

Its status page says "Meter: no reading for N seconds, limit 30 seconds" when
N passes 30; N is about half the file's run time. It failed alone under
--cpus 0.15 (94 s), in a loaded local parallel run (103 s) and in a loaded CI
run (112 s, run 1434). Idle it takes ~25 s. No test file changed, so it runs
alone after the parallel batch, like test_loop.py and test_freeze.py.

Co-Authored-By: Claude <noreply@anthropic.com>

.gitea/ci/run-tests.sh

@@ -29,8 +29,17 @@
 #                   16 s window, a 10 s hold and an alarm measured at 11.0 s:
 #                   one poll of margin, and "failed 1 run in 3" on the rig
 #                   transport (TEST-30, CI-06).
+#   test_safety87.py  builds a controller (CH65) whose meter reading is stamped
+#                   on the REAL clock, and section 8 asks its status page,
+#                   which says "Not ready - Meter: no reading for N seconds,
+#                   limit 30 seconds" once N passes 30. Measured by CI-15: N is
+#                   about half the file's run time (N = 45 s in a 94 s run, 48 s
+#                   in a 103 s run). The file takes ~25 s idle and took 45 s in
+#                   CI's first parallel run, so N was ~20 s of the 30. It FAILED
+#                   alone under --cpus 0.15 (94 s) and in a loaded parallel run
+#                   (103 s). No test file is changed here, so it runs alone.
 # Add a file here only with a measured reason, and say it in this list.
-SERIAL="test_loop.py test_freeze.py"
+SERIAL="test_loop.py test_freeze.py test_safety87.py"
 #
 # LONGEST FIRST (SAFETY-125's CI run, job 2580; then a local parallel run, seconds:
 # modes_p4 758, safety125 508 on hotfix-0.19.2 only, modes_p3 364, safety119 328,

.gitea/workflows/checks.yml

@@ -539,9 +539,10 @@ jobs:
       # runner's 60-minute cap. The loop now lives in .gitea/ci/run-tests.sh (it
       # comes from the merged tree, like the Dockerfile), so the same script runs
       # locally and here. It runs the longest files first, then the files whose
-      # assertions depend on the wall clock - test_loop.py and test_freeze.py,
-      # TEST-30 / CI-06, the reasons are in the script - ALONE, after the
-      # parallel batch, so no sibling can steal their CPU. Its output stays one
+      # assertions depend on the wall clock - test_loop.py and test_freeze.py
+      # (TEST-30 / CI-06) and test_safety87.py (CI-15) - ALONE, after the
+      # parallel batch, so no sibling can steal their CPU. The reasons are in
+      # the script. Its output stays one
       # PASS/FAIL block per file, in a file per file (never one shared /tmp/out).
       # A file that is not in the script's two typed lists still runs, in the
       # parallel batch: the list is a sort order, not a selection.