@edgehero/pi-dispatch v1.6.1

A patch release for two defects that had been live since v1.6.0. Both are silent in the direction that matters, so neither would have announced itself.

The wait check lease leaked

Upgrade if you use run.waitFor with a profile condition. The polled wait arm took a check slot before the supersede claim and released it only around the check itself, so a delivery that was superseded, or whose holder could not be verified, walked out still holding one.

At the default PI_WAIT_CHECK_SLOTS=1 that means a single superseded delivery stopped every wait check on that worker until it was restarted. The symptom pointed somewhere else entirely: held jobs kept throttling and eventually recorded wait-expired with reason max-wait-unchecked, which reads as "this deployment could not run the check often enough" when in fact no check could run at all.

Nothing to do beyond upgrading. Jobs already held are unaffected and resume checking normally.

The run record no longer trusts the container's own object

tokens and session.reason were copied out of the runner's exit line as they arrived, so a container could put an arbitrary key or string into the durable run record, which is documented as PII-free by construction. Both are now rebuilt from closed lists: tokens from the twelve keys the runner actually emits, and reason from the published session.reason enum.

A conformant image round-trips byte-identically, key order included, so recorded history does not change shape for anyone running a real job image. A key the runner omitted stays omitted rather than becoming null.

Verification

2977 tests, 0 failures. Every new assertion was mutation-checked: reverting either fix turns its own tests red.