Close SQLite connections so PHC acquisition cannot stall silently

[ahmadexp]

Problem

Raw PHC acquisition stopped a few minutes after the collector started. The
Observatory showed 0.0 / 1.0 Hz acquired and "Waiting for direct PHC samples",
while systemctl still reported the unit as active (running).

A sqlite3.Connection used directly as a context manager commits or rolls back
the transaction but never closes the handle. Both the PHC ring store and the
experiment recorder relied on that, so every recorded sample leaked a descriptor
pair. Measured on the reference host at 1 Hz:

• ~4 descriptors leaked per sample, reaching the 1024 soft limit in ~168 s
• the store contained exactly 168 rows at that point
• 337 × experiments.sqlite3 + 337 × its WAL + 169 × phc-samples.sqlite3 + 168 × its WAL

Once the limit was hit, /dev/ptp* could no longer be opened either, so
take_phc_sample() returned None and the loop no-opped indefinitely at 0% CPU
with nothing further logged. That is why the failure was silent and why a
restart appeared to "fix" it — a fresh process buys another ~168 s.

Changes

• Add an owning _session() context manager to both stores that commits or
  rolls back and then always closes. Applied to all 12 call sites, including
  the four with self._lock, self._connect() as connection: variants (one of
  which is record_phc, on the per-sample path).
• Log the idle/resumed transitions once each instead of every cycle, which had
  been filling the journal at the Sync cadence.
• Exit for a supervisor restart only after acquisition has worked and then
  stopped, which is the condition that indicates an unrepairable state
  (exhausted descriptors, revoked store path, PHC removed). A process that has
  never acquired now waits quietly for the cascade instead of restart-looping on
  a cold boot, where no namespaces exist yet.

Tests

tests/test_phc_store.py gains descriptor-lifetime coverage for both the ring
store and the experiment recorder. Two notes on making them meaningful:

• record_phc returns early without an active run, so the test starts a run and
  asserts the rows were actually written — otherwise it passes while exercising
  nothing.
• The probe calls gc.collect() before counting, so a descriptor still
  reachable after collection is a genuine leak rather than platform GC timing.

Both fail on the previous code and pass here. Full suite: 81 tests.

Verification on the reference host

Seven-stage cascade, 1 Hz, collector running this branch:

	before	after
descriptors	52 → 204 in 75 s	11, flat over 2.5 min
sqlite handles	193 and climbing	0
restarts	dies ~every 168 s	0
achieved_rate_hz	0.0	1.0000, healthy: true, 0 gaps

At the observed uptime the previous code would already have accumulated ~440
descriptors.