v0.15.0

Highlights

This release brings an agnostic software upgrade frontend, opt-in and
disabled by default.

• #123 — Software upgrades: Odio implements neither detection nor upgrade
  logic. It reads a result file written by an external detector (current/latest
  version, availability) and can trigger two systemd user units — one to
  re-check, one to run the upgrade — surfacing status, live run progress and a
  header badge in the UI.

✨ Features

• Agnostic upgrade frontend — GET /upgrade for detector status, plus
  POST /upgrade/check and POST /upgrade/start to trigger the configured
  units. Capabilities are additive: the result file alone enables read-only
  status, and each configured unit enables its trigger.
• Internal user units — configured upgrade units register as internal:
  triggerable, but hidden from /services and the event stream.
• Live run progress over a Unix socket — the upgrade script writes one JSON
  line per milestone (tmpfs, no SD-card write wear), relayed verbatim as
  upgrade.progress SSE events. The run verdict comes from the systemd job
  result (authoritative), independent of the script's self-report; in-flight
  state is mirrored in GET /upgrade so a client reloading mid-upgrade still
  sees it.

🎨 UI

• Upgrade status badge in the header, surfacing availability and live run
  state — language-agnostic, via icon and colour.

🧹 Internal

• New upgrade.info / upgrade.progress event types and an internal flag
  on the event Stream interface.
• cache.Value — a lock-free single-value holder.
• Upgrade backend configuration (upgrade: block, opt-in).

Full changelog: v0.14.0...v0.15.0