fix(web): the charts stop lying about time, and logging out logs you out

The stats charts drew every sample as an evenly-spaced slot, because recharts
defaults to a category axis. A capture that idled for two minutes rendered that
gap as a single step — so the one view you open specifically to find where the
time went was the view least able to show it. All three charts use a numeric time
axis now, so the spacing is the elapsed time.

They also joined samples across a session boundary into one continuous line,
implying a continuity that never existed: the stream stopped and somebody else
started a new one. A capture is split at each `session_id` change now. And the
live card plotted the whole capture-so-far every 2 s, re-serialising and
re-plotting an unbounded series for a capture left running all evening; it plots
a bounded tail and says so, with the full series still in the saved recording.

Logging out only deleted the browser's copy of the cookie. The session is
stateless, so a value captured beforehand — a shared machine, a shell history, a
TLS-inspecting proxy — stayed valid for its full 7-day TTL and there was nothing
the operator could do about it. Sessions carry an epoch now and logging out bumps
it, which invalidates every cookie issued so far. Verified end to end: a captured
cookie works, survives nothing across a logout, and a fresh login still works.

The rest:

- The update card could not show its own timeout warning. It was suppressed by a
  `job` field read from the last snapshot — which, when the host has gone away
  mid-job, is exactly the case the warning exists for. Nothing ever cleared the
  applying state either, so the card waited forever with no way out; there is a
  button now. "Check now" also surfaces the host's 429 instead of looking dead.
- A running install survives a reload: the job id lived only in component state,
  so refreshing lost sight of an install that was still running while the Install
  buttons stayed armed against a host that answers 409. The host keeps the list —
  ask it.
- An all-sources-failed catalog said "no plugins available". That is a successful
  request carrying nothing, not an empty store; it names the sources that failed.
- The Installed tab rendered "vundefined" for a plugin with no recorded version
  (nullable in the contract, typed required here).
- The Displays "In effect" badges were computed from the local draft, so they
  restated the operator's unsaved edits back to them as though the host had
  adopted them. They read the API's `effective` now. A failed background poll no
  longer replaces a form someone is editing, and leaving the page with unsaved
  edits prompts — the old `beforeunload` guard never fired for in-app navigation,
  which is how you actually leave.
- Enter or Space on a preset's rename/update/delete icon applied the preset
  instead of running the action: keydown bubbled to the card.
- Dates follow the console's locale, not the browser's. The dashboard's
  PIN-pending tile says "Waiting"/"None" instead of "●"/"—".
- The Bun entry warns when TLS is half-configured, or when PUNKTFUNK_UI_SECURE
  is set without it — both of which silently break login.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

web/src/api/store.ts

@@ -81,7 +81,9 @@ export interface StoreCatalog {
 
 export interface InstalledPlugin {
 	pkg: string;
-	version: string;
+	/** Nullable in the contract (`InstalledView.version`) — a CLI-installed plugin may carry no
+	 * recorded version. Typed required here, the Installed tab rendered the literal "vundefined". */
+	version?: string | null;
 	tier: StoreTier;
 	source?: string;
 	entry_id?: string;
@@ -226,6 +228,34 @@ export function useStoreRuntime() {
 const JOB_POLL_MS = 1_000;
 const JOB_MAX_FAILURES = 15;
 
+/**
+ * The host's recent jobs, used to RE-ATTACH after a reload.
+ *
+ * The in-flight job id lived only in component state, so reloading the page (or opening the console
+ * on another device) lost all trace of a running install while the Install buttons stayed armed —
+ * and the host takes one job at a time, so the next click just bounced off a 409. The host keeps
+ * the list; ask it rather than remembering.
+ */
+export function useStoreJobs() {
+	return useQuery({
+		queryKey: [...storeKeys.all, "jobs"] as const,
+		queryFn: () => apiFetch<StoreJob[]>(`${BASE}/jobs`),
+		// Only needed to find an orphaned job on mount; the job query itself does the live polling.
+		staleTime: 5_000,
+	});
+}
+
+/** The newest job that is still running, if any — what a fresh page should re-attach to. */
+export function runningJob(jobs: StoreJob[] | undefined): StoreJob | undefined {
+	if (!jobs) return undefined;
+	// The list is oldest-first, so scan from the end for the most recent live one.
+	for (let i = jobs.length - 1; i >= 0; i--) {
+		const j = jobs[i];
+		if (j?.state === "running") return j;
+	}
+	return undefined;
+}
+
 export function useStoreJob(id: string | null) {
 	return useQuery({
 		queryKey: storeKeys.job(id ?? ""),