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

hive-c0re/src/dashboard/state_snapshot.rs

@@ -375,7 +375,7 @@ pub(super) async fn api_state(
     .into_iter()
     .map(history_view)
     .collect();
-    let tombstones = build_tombstone_views(&state.coord, &containers, &transient_snapshot);
+    let tombstones = build_tombstone_views(&state.coord, &containers);
     let port_conflicts = build_port_conflicts(&containers);
 
     // Both operator-targeted and peer threads surface on the dashboard