v2.1.0 — Distributed Go runner agents

Distributed Go runner agents

Script execution is no longer tied to the same host as the management plane. Automator
now dispatches every script run to a standalone runner — a small Go agent that can
live on any Linux or Windows host, registers securely, and streams output back in real
time. Multiple runners are supported, so a fleet can offer different capabilities
(Windows-only scripts, specific tool availability, network placement, etc.).

Why

The previous model ran scripts inline in the Laravel queue worker on whatever single
Linux host was hosting the app — cancellation even relied on the web request and the
executing process sharing a PID namespace. That made it impossible to run scripts
anywhere but the one box Automator itself was installed on.

What changed

• New execution model: script runs are assigned to a registered Runner (least-busy
  among online runners, with tag-based routing via required_runner_tags) instead of
  running inline in a local queue worker.
• Secure registration: a one-time enrollment token exchange issues each runner a
  Sanctum bearer token; revoking a runner from Settings → Runners immediately cuts it off.
• Real-time job delivery: runners receive job assignment/cancellation over a private
  Laravel Reverb WebSocket channel — the same broadcasting layer already powering the
  browser's live output terminal — and report output/heartbeats back over authenticated
  HTTPS REST.
• Heartbeat-based offline detection: a runner that misses its heartbeats is marked
  offline and any of its in-flight executions are automatically failed with a clear
  "runner disconnected" message — no silent hangs.
• Full cancellation support: SIGTERM on Linux; CTRL_BREAK_EVENT with a
  hard-kill fallback on Windows.
• No local execution fallback — every run, including on a single-box install, goes
  through a registered runner. Install scripts now auto-register a local runner on the
  same host during setup, so single-box installs still work out of the box.
• Removed: RunScriptJob, the executions queue, automator-worker@.service, and
  the global max_concurrent_executions setting (replaced by per-runner
  max_concurrent_jobs).

See docs/ARCHITECTURE.md, docs/DATA_MODEL.md, and docs/RUNNER_PROTOCOL.md for the
full technical reference.

Upgrading

Existing installs should re-run the packaged install script (or pull the new
packaging/ scripts), which now provisions and registers a local runner automatically
during setup. Additional runners — Linux or Windows, on any host — can be registered at
any time from Settings → Runners.