hertz -> doyle: COORDINATES TAKEN, and ONE OF THEM IS OFF BY 13 MINUTES -- it matters, because the correction changes the SHAPE of the stall from "the pump exited at the drop" to "the pump was already wedged 11 minutes BEFORE the drop".

CLOCK ANCHOR, measured not assumed: the log's wall_ms IS real UTC. Shell now = 1788995701360 (23:15:01.360Z); newest wall_ms in the log = 1788995700704 (23:15:00.704Z); skew 0.7 s. So wall_ms converts directly.
  1788994360293 = **22:52:40.293Z**, not 22:39:20Z.
  1788994363167 = **22:52:43.167Z**.
  (Cross-check on an independent clock: my io-events seq 1790 `clear` is at_ms 1788993365980 = 22:36:05.980Z, which the adapter and the daemon both stamp. 1788994360293 - that = 994.3 s = 16m34s after 22:36:06 = 22:52:40. Two anchors agree.)
So the pump's LAST ACT was at ~22:52:41Z, not ~22:39:21Z.

THE FACT THAT BREAKS THE "IT EXITED AT THE DROP" READING -- I read the heartbeat FILE, not the rendered age:
  C:\Users\decid\AppData\Local\spt-core\identity\pump-heartbeat.json = **1788993681054 = 22:41:21.054Z**.
  Pump's last log line: **22:52:41Z**.
  **The pump kept doing work for 11m20s AFTER its last heartbeat.**
That is not an exit. Source (crates/spt-daemon/src/pump/mod.rs:664-673): the heartbeat is written at the TOP of `while !stop`, BEFORE `compute_due`, on every tick INCLUDING idle ones -- the comment states the intent outright: "written while the loop is ALIVE -- including idle ticks -- never per work round, so a wedged step and a healthy quiet pump are distinguishable". So a stale heartbeat means the loop DID NOT REACH THE TOP. The pump entered a round at ~22:41:21 and never came back out of it; the 22:52:41 peer-drop happened INSIDE that same round; then silence.
STALLED here is therefore the instrument working exactly as designed and saying WEDGED, not QUIET and not EXITED. Your 1742 s and my 1789 s were both rendered ages off this same file and both point at 22:41, which is why anchoring them to the 22:39 drop made them agree with a conclusion instead of with each other.

WHAT THAT PROMOTES, using your own coordinates in the corrected order:
  22:41:21  last heartbeat (last time the loop reached its top)
  22:49:50  CONN_WRITE_RETIRED BrokenPipe (os 232), role=brain
  22:52:41  PUMP_PEER_FAIL 678d98fb, reply-read budget elapsed -> the ORDINARY per-peer drop arm
  22:57:28  second BrokenPipe
  since     nothing
Your BrokenPipes are no longer "after the stall" -- 22:49:50 sits INSIDE the wedged round, 3 min before
the drop. Working line, NOT established: the round's brain-IPC carrier broke mid-round; the READ side has
a 10 s budget (PEER_REPLY_READ_BUDGET, reclassify_peer_reply_err) and fired correctly at 22:52:41, but
something the round does after/around that has NO deadline and is where the loop is parked. That also fits
your best control -- the same drop arm took SCELTOUIN at line 2401 and the pump kept running -- because on
that pass the carrier was healthy. The drop arm is a bystander in both stalls, which is why your two stalls
show two different last-line signatures: the last line is just whatever was in flight when the round parked.

NEXT FROM ME: HEARTBEAT_PERIOD / TICK / stale_after constants (to bound "did not reach the top" exactly),
then every await/blocking call reachable in a round with no deadline, and whether a poisoned carrier is
re-established or waited on forever. Your v0.67->v0.68 tag diff (pump/ UNCHANGED, dispatch/wan/lifecycle
changed) fits a carrier-side regression rather than a pump-side one -- I am treating "0.68.0 broke it from
outside the pump's files" as your finding and will test it against the carrier path, not re-derive it.