v0.8.3

0.8.3: a dropped websocket no longer cancels running steps

Fixed

• Runner: a dropped websocket no longer cancels the steps the runner is
  running. Before, any transport failure (no close frame received or sent, keepalive ping timeout, a rolling API deploy) tore down every
  running step before reconnecting, so a four-second blip killed hours of
  work (the org-root dataset-scout seed step, 2026-11-09, three drops in
  eighteen minutes). Now only the connection's own tasks (monitoring, the
  stop-signal and command listeners) are rebuilt on reconnect. A step that
  finishes while the runner is disconnected holds its result (its last log
  lines and the completion) until the connection is back and retries the
  report for up to 10 minutes; after that it logs the loss and drops the
  result. A completion the server no longer accepts (the step was failed,
  canceled or timed out there while the runner was offline) is logged and
  absorbed, never a crash. A real shutdown (Ctrl-C, SIGTERM) still cancels
  running steps as before.
• Runner: finished step tasks are removed from the daemon's task list, so
  the shutdown path and its "Exiting N active step(s)" line count the
  steps really in flight (the list only ever grew before: 71, 74, 77 across
  three reconnects on the same day).
• Runner: a claim that fails because the connection just dropped is logged
  and the step is left for the next connection to pick up (the server
  offers unclaimed steps again on connect), instead of dying silently.
• Runner: a step whose final log upload fails is still reported as
  finished; the lines go out with the completion.

Changed

• Runner: a step's log lines stream to the server every 3 seconds while
  the step runs (before, one batch was sent 10 seconds in and the rest
  only at the end), so the run page and a chat turn's live view show
  them as they are printed. A batch that fails to send is kept and goes
  out with the next one.
• Runner: datatorch.runner.serve_forever(client, transport) is the
  connect-serve-reconnect loop start() runs, with one RunnerDaemon
  across connections (daemon.serve(session) per connection). The
  one-shot RunnerDaemon.run(session) still works for outside callers.