MicroscopeControl 0.2.6

[kalidke]

Release 0.2.6 into main, as one PR. Admiral and the captain agreed this shape on 2026-09-29, the same as #71
for 0.2.5.

This branch starts at #72's head (7acee6c, the 0.2.6-DEV bump). It then has merge commits of three reviewed PRs,
followed by the 0.2.6 version commit:

• PI stage: connected only after a full initialize, a reset id, a wait for the controller, and fake-GCS2 tests #73 (4618582): PI stage fixes, with checked status returns and a bounded wait for motion to stop.
• TCube safety fixes from the 642 rig's facts: fresh reads request twice, two-sided check_lock, calibration reference (0.2.6) #74 (4e73adf): TCube laser safety fixes from the 642 nm rig's controller facts.
• DCAM4 capture: bound every wait, arm it before the start, clean up on every exit #75 (bcfa0be): DCAM4 capture. Every frame wait is bounded and armed before the start, and every exit cleans up.

Each head is the one the captain accepted after review. The only conflicts were in CHANGELOG [Unreleased], and
both sides are kept under each heading. A check confirmed that every line of each PR's [Unreleased] survives.
Every file each PR changed (other than CHANGELOG, Project.toml and test/runtests.jl) is byte-identical in
this branch to that PR's head. test/runtests.jl carries all three PRs' additions.

Project.toml is 0.2.6, with no -DEV, so TagOnMerge tags v0.2.6 once lab/tests covers the merged tree. The
CHANGELOG has one [0.2.6] section, with a short line per part: PI stage, TCube laser safety and DCAM4 capture.
There are no code changes beyond the merges.

Compatibility (decisions 0033 and 0035): non-breaking. Each PR states its own case. The deliberate behaviour
changes, with the CHANGELOG heading each is under:

• TCube calls take longer (Changed).
• A lock_check_s below 0.1 s is refused (Fixed: 0 used to disable the lock check).
• PI initialize waits for PI_IsControllerReady (Changed).
• DCAM4 capture refuses while a live view or sequence runs (Changed).

Hardware: the DCAM4 fix is confirmed on the quickbeam rig. Nothing else has run on a rig yet.

• The rig ran trial branch t16/v0.2.4-dcam4 (97d26f6), which is v0.2.4 plus DCAM4 capture: bound every wait, arm it before the start, clean up on every exit #75's camera files, byte-identical to
  bcfa0be. In a fresh kernel it took full-frame captures at 12.5 ms (x20), 100 ms (x3) and 250 ms (x3), all good,
  with no timeouts and no hangs. A 256x256 capture afterwards needed no reconnect, and check_hardware was 10/10 OK.
• Still owed from R5 in DCAM4 capture: bound every wait, arm it before the start, clean up on every exit #75: the forced-timeout check and the sequence check. The one-shot diagnostic did not need
  to run.
• The rig checks for the rest are listed in the PRs: PI stage: connected only after a full initialize, a reset id, a wait for the controller, and fake-GCS2 tests #73 (the C-867 startup check), and TCube safety fixes from the 642 rig's facts: fresh reads request twice, two-sided check_lock, calibration reference (0.2.6) #74 (R1-R4, plus the
  642 nm rig's first calibration reference).
• Follow-up, not in 0.2.6: a full-frame capture takes 760-870 ms at a 12.5 ms exposure (the first one 1626 ms). It
  is worth profiling.

Tests: the local suite on this head (kitt, Julia 1.13) is 2010 pass, 3 broken, 0 fail. The two commits after the version commit change only CHANGELOG (review nits N2-N5, and the rig confirmation). The PRs' records were
1890 (#73), 1919 (#74) and 1836 (#75) against a base of 1816, which predicts exactly 2013. lab/tests and lab/docs
on this head follow as commit statuses.

🤖 Generated with Claude Code