laser power-good: the line characterized, the kernel-drill guard, the probe, the dev image's mmap and ctypes

The supply's power-good line is active high, static across HV enable and emission, and driven; the facts bank and CAMPAIGN-LOG carry the measurement and the item closes. The kernel-drill latch-unlock guard read the old inverted value as HV not good, a check that was vacuous and would refuse every run once the module reads the line correctly; it now uses the chain's own witnesses, the charge-pump watchdog and the engine state. pgood_probe.py watches the line beside the chain through the kernel readbacks and is registered on the bench page. The dev image lists python3-mmap and python3-ctypes again for the pad-level bench tools the python trim had left without them.

docs/BRINGUP.md

@@ -324,8 +324,10 @@ from the kernel counters. Contract: [forgectrl](https://docs.forgefirm.org/techn
 **Emission evidence.** `cnc/laser_on_sampled` (surfaced as `/status`
 `laser.emission_samples`) is the reliable live-emission witness; emission
 sensed with no armed window relocks the latch and stops motion. `pic/hv_current`
-is the only live HV telemetry on this PSU. `cnc/laser_pgood_sampled` is **not**
-a usable witness here — it reads 0 through real cutting.
+is the only live HV telemetry on this PSU. `cnc/laser_pgood` is the supply's
+power-good, driven high the whole time the supply is healthy (it follows
+neither HV_ENABLE nor emission): a supply-fault witness, never an emission
+witness (facts bank "Emission and HV witnesses").
 
 ## Lid, interlock and button policy
 
@@ -1031,8 +1033,22 @@ is committed.
   count on a commanded fire window and returns to 0 at Idle — the reliable
   witness. `pic/hv_current` tracks the cut (0 idle → hundreds/1023 raw while
   firing) and is the only live HV telemetry on this PSU (`hv_voltage` is
-  grounded). `cnc/laser_pgood_sampled` stays 0 through real cutting: not usable
-  here.
+  grounded). **`cnc/laser_pgood` (J1_14, GPIO4_21) is the supply's power-good,
+  active high**, measured 2026-09-01 through the kernel readbacks at ~780 Hz:
+  the pin is high at idle, through four HV_ENABLE cycles of a dry run, and
+  through an armed S400 cut (714 laser pulses, `hv_current` to 1023), with
+  zero transitions in 225 s, and it stays high against a 100 kΩ pull-down
+  switched in at the pad (IOMUXC `0x020E03C4`, restored to `0x100b0`), so the
+  supply drives it. The supply's supervisor is a Weltrend WT7525 (PC-supply
+  supervisor; open-drain PGO reports every DC output within spec, drops on an
+  over/under-voltage or over-current fault, 300 ms delay after good), and the
+  reverse-engineering pinout sheets label J1_14 `HV_PFC_STOP` (TP_A2C). The
+  factory app reports the line as the `HVpg`/`HVps` tags and read it the same
+  way (0 at idle under the old inverted convention). The kernel now reads it
+  active high: `laser_pgood` 1 and `laser_pgood_sampled` 255 on a healthy
+  supply; a drop during an armed window is the cooling engine's supply
+  power-good warning, and it means a supply fault. The line has never been
+  seen low on this machine.
 - **The head MCU flag register and HEAD_IRQ.** The head MCU (a KL17 at
   i2c-3 @0x47, I²C-slave-only to the SoC) samples four head-local GPIO input
   levels once per main loop into the read-only flag register 0x05: b0
@@ -1270,19 +1286,7 @@ feature requests, enhancements) will eventually be tracked as GitHub issues.
     far): re-measure the two heat coefficients and the machine's
     air-assist offset; and if a lit check still trips, the
     void-on-emission design with the tube as its own flow tracer.
-8. **Laser power-good: what the line means.** `cnc/laser_pgood` and its
-    sampled count are defined in the UAPI (active low, one sample every
-    ~3.9 ms), the facts bank records that the sampled count reads 0 through
-    real cutting, and the cooling engine warns
-    `laser power-good degraded during the armed window` whenever fewer
-    than half the samples read low, so the warning fires at every session
-    open and carries no information. Nobody knows what the line reports
-    on this PSU: whether it is the supply's own power-good, an HV-present
-    flag, a polarity we have inverted, or unconnected. Owed: the line on a
-    scope against `hv_current` through an armed cut, its meaning written
-    into the facts bank and the UAPI, and then either a warning that means
-    something or no warning.
-9. **Initial commissioning: measure and set the machine's own numbers
+8. **Initial commissioning: measure and set the machine's own numbers
     methodically.** Every tunable that was measured on the bench machine
     and shipped as a default varies from machine to machine: the flow
     check's bands and `cool_flow_rise`, the tube's heat coefficients

docs/CAMPAIGN-LOG.md

@@ -6977,6 +6977,48 @@ from the LAN by `live_fire_drills.py`, the operator on the button:
 Items 7 and 8 are bench-proven. The board runs the hot-deployed binary
 until the next flash.
 
+## 2026-09-01: the laser supply's power-good line, characterized without a scope
+
+The "laser power-good" item asked what J1_14 reports. No scope on the
+bench, so the line was read through the kernel's own readbacks with a
+new probe (`scripts/bench/pgood_probe.py`, fed to the board over ssh
+stdin) at 770 to 790 Hz, against LASER_ON, FIRE, the charge-pump
+watchdog, HV_ENABLE and the doors from the switch device, and
+`hv_current` at 20 Hz. Image 20260901220626 (dev), fresh boot.
+
+- **Dry run, 75 s.** Four jogs; `charge_pump_alive` and HV_ENABLE rose
+  and fell together within 5 ms at every run start and end. The pin
+  stayed high for every one of 59,518 samples.
+- **Armed run, 150 s**: the `witness` drill, a 20 mm square at S400 F600.
+  714 LASER_ON pulses over 8.0 s, `hv_current` 0 to 1023, HV_ENABLE up
+  for the run. The pin stayed high for every one of 115,872 samples.
+- **Driven, not floating.** With a cross-built register tool the pad's
+  internal pull was switched to 100 kΩ pull-down (IOMUXC `0x020E03C4`,
+  `0x100b0` to `0x130b0`), then pull-up, then restored; the pin read
+  high under all three and the pinctrl view confirmed the restore.
+- **What the supply has.** The reverse-engineering archive holds the
+  supply's datasheets and board photos: the supervisor board carries a
+  Weltrend WT7525 (PC-supply supervisor: open-drain PGO high once every
+  DC output is within spec, low on an over/under-voltage or over-current
+  fault, 300 ms delay), LM2901 comparators and four PC817 optocouplers.
+  The pinout and test-point sheets label J1_14 `HV_PFC_STOP` (TP_A2C).
+  The factory app reports the line as the `HVpg`/`HVps` header tags and
+  its logs show 0 at idle under the same inverted convention the module
+  inherited.
+
+Disposition: J1_14 is the supply's power-good, active high, static across
+HV enable and emission, and driven. The module now reads it active high
+(`laser_pgood` 1, `laser_pgood_sampled` counts good samples, 255 on a
+healthy supply); the cooling engine's once-per-session warning keeps its
+threshold and now means a supply fault; the catalog's kernel-drill
+precheck, which read the old value as "HV not good", moves to the chain's
+own witnesses. The line has never been seen low; a supply fault is the
+only thing that would take it there. Owed: the change rides the next image
+(kernel module), and the dev image regains `python3-mmap` and
+`python3-ctypes`, which the python trim removed and which
+`resume_dark_lead.py`, `cp_watchdog_timing.py` and the accelerometer
+probes need.
+
 ## Reference notes
 
 ### Head-IRQ source validation — the beam-emission hypothesis