P3-01/02/03: restore wizard backend + templates + restore-shaped job page

End-to-end wizard from /hosts/{id}/restore (or per-snapshot deep link
/hosts/{id}/snapshots/{sid}/restore) → tree-browse → dispatch →
restore-shaped live job page.

Backend (internal/server/http/ui_restore.go):
- GET handlers render the four-step wizard against the wireframe shape
  in docs/superpowers/specs/2026-05-04-p3-restore-design.md.
- HTMX tree partial endpoint hits fetchTreeWithCache (P3-X2) so each
  directory expansion is a sub-second cached lookup after the first
  miss.
- POST validates: snapshot_id non-empty, ≥1 absolute path, in-place
  mode requires confirm_hostname == host name, agent online. On error
  re-renders the wizard with the operator's input intact. Happy path
  mints a job_id, computes the new-directory target as
  /var/restic-restore/<job-id>/ (operator can't escape the prefix —
  server picks it), creates the job row, ships command.run with
  kind=restore + RestorePayload, writes a host.restore audit row,
  returns HX-Redirect (or 303) to the live job page.

Templates:
- host_restore.html: single-page progressively-enabled wizard matching
  _diag/p3-restore-wizard wireframe. Form-state-driven JS computes a
  running tally of selected paths and the step-4 confirm summary
  client-side; the server re-renders on validation failure with form
  fields preserved.
- partials/tree_node.html: recursive HTMX-served tree fragment.
- Top-level Restore button on host_detail right rail + per-snapshot
  Restore action on snapshot rows replace the previous P3-stub.

Restore-shaped job page (job_detail.html):
- Progress widget rendered as a panel rather than a bare strip when
  the job is active.
- Current-file display under the bar, updated from log.stream stdout
  lines that look like absolute paths. Hidden for non-restore kinds.

Migration 0012:
- Add restore + diff to the jobs.kind CHECK. Rebuild required (SQLite
  can't ALTER CHECK in place); follows the safe pattern from 0005.
  Defensive: stash job_logs into a temp table before the rebuild and
  INSERT OR IGNORE back afterwards so even if SQLite cascades on
  DROP TABLE jobs the log history survives.

Tests:
- ui_restore_test covers GET step-1 render, GET pre-selected snapshot
  summary card, POST missing snapshot, POST missing paths, POST
  in-place wrong-hostname rejection (no command.run leaks to the
  agent), POST happy path (HX-Redirect + correct payload + audit
  row), POST against offline host returns 503.

Restage block (CLAUDE.md) deferred to the end of the restore phase.

internal/store/migrations/0012_jobs_restore_diff_kind.sql

@@ -0,0 +1,61 @@
+-- 0012_jobs_restore_diff_kind.sql
+--
+-- Add 'restore' and 'diff' to the jobs.kind CHECK constraint so the
+-- restore wizard (P3-01) and the snapshot-diff endpoint (P3-09) can
+-- persist their job rows. SQLite can't ALTER a CHECK in place, so we
+-- rebuild the table.
+--
+-- Rebuild safety: jobs has an inbound FK from job_logs (ON DELETE
+-- CASCADE) and from schedules.jobs is referenced via scheduled_id.
+-- CLAUDE.md flags DROP TABLE on a parent as risky under
+-- foreign_keys=ON; we mitigate two ways:
+--
+--   1. Stash job_logs into a temp table BEFORE rebuilding jobs, then
+--      restore the rows after the rebuild settles. If a cascade
+--      misbehaves we can still recover.
+--   2. Use the safe rebuild order from 0005: create jobs_new with the
+--      wider CHECK → copy data → DROP jobs → RENAME jobs_new TO jobs.
+--      Do NOT rename the original first (the dangling-FK trap that
+--      0005's first draft hit and 0006 cleaned up).
+
+CREATE TEMPORARY TABLE _job_logs_backup AS
+  SELECT job_id, seq, ts, stream, payload FROM job_logs;
+
+CREATE TABLE jobs_new (
+  id              TEXT PRIMARY KEY,
+  host_id         TEXT NOT NULL REFERENCES hosts(id) ON DELETE CASCADE,
+  kind            TEXT NOT NULL CHECK (kind IN
+                       ('backup','init','forget','prune','check','unlock','restore','diff')),
+  status          TEXT NOT NULL CHECK (status IN ('queued','running','succeeded','failed','cancelled')),
+  scheduled_id    TEXT REFERENCES schedules(id) ON DELETE SET NULL,
+  actor_kind      TEXT NOT NULL CHECK (actor_kind IN ('user','schedule','system')),
+  actor_id        TEXT,
+  started_at      TEXT,
+  finished_at     TEXT,
+  exit_code       INTEGER,
+  stats           TEXT,
+  error           TEXT,
+  created_at      TEXT NOT NULL
+);
+
+INSERT INTO jobs_new
+  SELECT id, host_id, kind, status, scheduled_id, actor_kind, actor_id,
+         started_at, finished_at, exit_code, stats, error, created_at
+  FROM jobs;
+
+DROP TABLE jobs;
+
+ALTER TABLE jobs_new RENAME TO jobs;
+
+CREATE INDEX jobs_host_id ON jobs(host_id);
+CREATE INDEX jobs_status ON jobs(status);
+CREATE INDEX jobs_created_at ON jobs(created_at);
+
+-- Defensive: if cascade-on-DROP wiped job_logs (it shouldn't with the
+-- foreign_keys behaviour SQLite documents, but the codebase has hit
+-- "lost rows" before during rebuilds), restore from the temp backup.
+-- INSERT OR IGNORE so re-running is harmless.
+INSERT OR IGNORE INTO job_logs (job_id, seq, ts, stream, payload)
+  SELECT job_id, seq, ts, stream, payload FROM _job_logs_backup;
+
+DROP TABLE _job_logs_backup;