0.141.0: A run says when it is writing findings, and email links no longer open a dialog

humanish 0.141.0 says when a run is writing its findings: the CLI prints progress with the
elapsed time, humanish runs and the TUI show analyzing, and the Observer's Findings tab shows a
pending state from the moment analysis starts. A run cut off before it publishes is recorded as
interrupted, reclaim marks a dead run, a killed analysis no longer blocks the next one, and
run prints the run id as soon as it exists. On hosted and local desktops, a mailto:, tel:
or sms: link no longer opens an app chooser or a browser prompt that participants reported as an
app fault: humanish records the link and tells the participant that nothing was sent.

Changed

• A run says it is analyzing while its automatic analysis runs. status.json gains
  analysis: { startedAt, endedAt?, state? } and its heartbeat keeps running through the
  analysis. humanish runs lists the run as passed, analyzing (or its other result), and
  runs --json carries analysis. The TUI adds analyzing to the run. The served Observer's
  status band reads Writing findings and the Findings tab shows a pending state with how long
  ago analysis started, from the moment it starts. In a terminal, run prints Participants finished. Writing findings; this usually takes 1 to 4 minutes. and then the elapsed time every
  20 seconds; --json prints only the first line, on stderr.
• run and watch print Run <id> started. Follow it with humanish observe --run <id> to stderr
  as soon as the run exists, --json included. Library callers get a run-started event with the
  run id through onEvent; a TypeScript switch over StudyEvent["type"] that must be
  exhaustive needs a case for it.
• The humanish skill has a section on long studies: run blocks until the participants and the
  analysis finish, how to start one in tmux, and how to find and follow it with runs --json and
  review.

Fixes

• A run whose process leaves it without publishing a bundle, as a route that throws does, is
  recorded interrupted with reason: no-publish. Before, it was recorded finished with no
  outcome, and counted in the study's duration medians.
• humanish reclaim --run <id> marks a run whose status heartbeat went stale as interrupted
  (reason: reclaimed) and says so. Before, a killed run read as running in its status record
  forever.
• humanish analyze analyzes an interrupted run whose participant streams all ended. When it
  refuses a run, it says why and names the next command: humanish runs for a run still running,
  humanish run <study> for one cut off mid-participant, and humanish reclaim --run <id> for one
  whose heartbeat stopped while its pid is still in use. Before, every case said "Wait for the
  study to finish."
• humanish review says participants are still running, or that the analysis is running and when
  it started, before findings exist. Before, it said "No analysis has run for this run." An
  analysis whose process stopped before it finished gets its own message
  (AUTOMATIC_ANALYSIS_STOPPED) and the analyze command that runs it again, instead of "records
  could not be read or checked". A run that ended while a participant was still running says so and names
  humanish run <study>.
• A run's .analysis-lock records the process that took it (host, pid namespace, pid and start
  time, as reclaim --preflight reads a probe's owner). When that process is gone, as after a
  killed analysis, the next analyze takes the lock over and says so in a warning, instead of
  refusing with ANALYSIS_BUSY until someone deletes the directory. A lock whose owner is still
  running, runs on another host, or was written by an earlier version still refuses.
• Email and desktop cleanup messages no longer call the step "finalization".
• A participant on a hosted desktop (E2B or Modal) who clicks a mailto: link no longer gets
  XFCE's "Choose Preferred Application" dialog, and a tel: or sms: link on the study's own
  site no longer opens Chrome's "Open xdg-open?" prompt. Participants had reported both as faults
  of the app under test. On the local browser route a mailto: link did nothing and a tel:
  link opened the same prompt; a runtime image built from this release records both instead. The desktop has no email, phone or messaging app, so it now writes the
  link down. The trace records a link opened another app notice with the scheme and, for an
  email link, only the recipient addresses. The participant's next turn says the link worked,
  that the app is not shown and that nothing was sent, and automatic analysis is told the missing
  app window belongs to the study desktop.
• A local browser participant's mailto:, tel: and sms: links are recorded the same way. This
  release pins runtime-2026.10.21.3 (amd64) and runtime-2026.10.21.4 (arm64), which carry the
  stand-ins; humanish runtime setup installs them. An older local runtime keeps the old
  behavior: Chrome's prompt for tel:, and nothing for mailto:.