fix(browser): report creation-order indices and target the newest active claim

Round-five Opus findings (both reviewers converged independently):

P1 — 'tab show', 'tab current' and 'tab switch --page' reported the
bridge's registration index, which any park+wake permutes (unregister
deletes the map key, re-register appends). The listing speaks creation
order, so the reported number named a different tab than the listing —
and chaining it into '--index' closed the wrong tab. Every index a
headless caller sees now comes from the same creation-ordered listing.

P1 — the strict parked-active claim let one flag exist per scope, but the
scope-less implicit target still scanned broadly and returned the FIRST
flagged page in creation order — the oldest scope's page, not the page
that actually held the most recent active claim. It now prefers the most
recently used flagged page, matching the bridge's global-pointer
semantics; scoped queries see at most one flag and are unchanged.

P2 — closeTab's promotion gate called getActivePageId, which resolves
through resolveActiveTab and reassigns the bridge's active pointers as a
side effect (the exact mutation this PR's own comment warns against),
and its undefined scope meant 'anywhere' while the promotion is strict.
The gate now reads the page book: promote only when the closed page's
scope holds no resident page.

P2 — an idle/grace window past 2^31-1ms (reachable via the documented
'set it very high' advice, e.g. 1e10) overflowed setTimeout, which Node
clamps to 1ms — a permanent spin. The armed delay is now capped at the
setTimeout ceiling; re-checking at the horizon is harmless. Invalid knob
values also warn instead of falling back silently.

P2 — the docs sold the download veto as a guarantee; reworded to what
ships: a decision-time veto, with downloads that begin during teardown
still cancelled, exactly as if the tab had been closed at that instant.

docs/reference/headless-linux-server.md

@@ -293,8 +293,10 @@ storage live in the profile partition and survive, but an unsubmitted form or
 an SPA's in-memory state does not. A page is never parked while a paired
 client is streaming it, while a command against it is in flight, while its
 initial load is still running, while it is waiting on a certificate decision,
-while a wake is still rebuilding it, or while it is writing an active
-download — parking cancels a download, so an active one always vetoes it. A stream ending counts as use, so a viewer who closes the pane gets
+or while a wake is still rebuilding it. An active download vetoes the park
+decision — parking cancels downloads — but a download that begins during the
+teardown itself is still cancelled, exactly as if the tab had been closed at
+that instant. A stream ending counts as use, so a viewer who closes the pane gets
 the full idle window before the page parks, even if they only watched. A navigation that has still not finished by the load timeout is
 deliberately reclaimable — otherwise one stalled page per create could hold a
 renderer forever, which is the failure this exists to prevent; waking it simply