fix(#3020): K3PT ST4T3 says what it shows, and stops reading the job graph

`build_tombstone_views` folded `transient_snapshot`'s keys into its `live`
set, so an agent with in-flight transient work was treated as not-a-tombstone.
Since #3010 that set is derived from the running job graph, which made a
page about on-disk state a function of the scheduler.

Dropping the filter exposes what was always true underneath: nothing records
a destroy. Every definition-side artifact — state subvolume, proposed +
applied repos, `deployed/0`, meta registration, topology entry — is written by
`Provision` before the container exists and survives `lifecycle::destroy`. So
a mid-spawn agent is byte-identical on disk to a tombstone.

Per mara on #3020: remove the filter, warn on the page, keep the issue open
for the swarm-controller / snapshot-storage rework where the problem shape
changes anyway.

- dashboard/tombstones.rs: drop the param + the chain; document the real
  semantics
- core.js: amber caveat banner above the rows; row badge `destroyed` ->
  `offline`, which is what an absent container actually proves
- dashboard.css: `.tombstone-warn`, modelled on `.port-conflict` but amber and
  without the pulse — a permanent banner that pulses trains you to ignore it
- docs/web-ui/dashboard.md: the pane was described as "destroyed-but-state-kept
  agents", now the exact wrong claim

docs/web-ui/dashboard.md

@@ -136,11 +136,22 @@ page — see below.)
 
 **K3PT ST4T3** — two sub-sections on one pane:
 
-*Tombstones*: destroyed-but-state-kept agents (size + age +
+*Tombstones*: agents with kept state and **no container** (size + age +
 claude-creds badge). Two actions: `⊕ R3V1V3` (queues a Spawn
 approval; existing state is reused), `PURG3` (wipes state + applied
 dirs; `POST /api/purge-tombstone/{name}`).
 
+⚠️ **Not only *destroyed* agents.** Nothing records a destroy: every
+definition-side artifact (state subvolume, proposed + applied repos,
+meta registration, topology entry) is written by `Provision` *before*
+the container exists and survives `lifecycle::destroy`. So an agent
+part-way through a spawn is byte-identical on disk to a tombstone, and
+both are listed. The pane carries a standing warning to that effect, and
+the row badge says `offline` rather than `destroyed` — the absence of a
+container is all the backend can actually prove. Fixing it properly
+needs a recorded destroy: **#3020**, deferred to the swarm-controller /
+snapshot-storage rework where the problem changes shape.
+
 *Stale permission entries*: agents with explicit capability or
 tool-group JSON entries but no live container — typically renamed or
 deleted agents whose entries persisted in `capabilities.json` /