fix(auth): close P1/P2/P3 — JWKS stall, 12h session, cookie shadowing

All three deferred findings from the qe-court round. Each fix is guarded by a
test confirmed to FAIL against the old behaviour.

P1 — JWKS: self-inflicted stall, and a blocking fetch on a tokio worker.

`fetched_at` advances only on SUCCESS, and the only rate limiter sat behind
`if fresh`. So once the TTL elapsed after the last successful fetch, `fresh`
was permanently false, the limiter was never consulted, and EVERY request
performed its own blocking 3s-timeout fetch. A Pi that loses WAN stalled
itself 300s later with no attacker present; an attacker could force the same
state by flooding tokens with an unknown `kid`.

Now: `last_attempt_at` is recorded BEFORE every fetch regardless of outcome,
and gates the stale path too; a stale-but-present key is served rather than
erroring, which is the offline tolerance this module always claimed.
Measured by the new test: 26 outbound fetches before, 1 after.

Kept as TWO independent limiters. Merging them looks tidy and is wrong — a
routine refetch would then suppress the unknown-`kid` path for 30s and delay
pickup of a key rotation inside the TTL. I made that mistake first; two
existing tests caught it.

The blocking call also now runs in `spawn_blocking` at the verify boundary,
matching what `main.rs` already does for the token exchange, where the comment
reads "the same mistake this codebase had to fix in jwks.rs". The hot
verification path had never been given the same treatment. A panicked task
fails closed.

P2 — session lifetime, per decision: 1 hour, plus step-up.

SESSION_TTL_SECS 12h -> 1h, and privileged (`sensing:admin`) actions now
require the user to have authenticated within ADMIN_REVERIFY_SECS (5 min),
tracked by a new `auth_time` claim. Reads ride the full session; only the
routes where a stale session does damage are re-verified, so a dashboard whose
main use is watching a live stream does not re-auth hourly.

`auth_time` is `#[serde(default)]`, so a cookie issued before the field existed
reads as 0 — infinitely stale. Such a session keeps working for reads and
cannot perform privileged actions. Fail-closed and self-healing on next sign-in.

The refusal carries an RFC 6750 `WWW-Authenticate` error code, because the
client's correct response differs from a plain 401: the user IS signed in and
needs to prove it again. `api.service.js` acts on that and redirects through
`/oauth/start` — otherwise a stale-session delete surfaces as a generic
"Request failed" with no hint that signing in again fixes it.

P3 — cookie shadowing.

`read_cookie` returned the FIRST match, and RFC 6265 §5.4 sends longer-`Path`
cookies first. Cookies are not isolated by port or scheme, so any other service
on the host — or a plain-HTTP MITM injecting Set-Cookie — could plant
`ruview_session=<their own validly signed session>; Path=/ui`. The victim sent
both, the attacker's first, and it verified because it genuinely was signed:
silent session takeover, with `/oauth/status` reporting the attacker's account.

The signature was doing its job throughout, which is why "it's signed" never
answered this. `__Host-` would, but requires `Secure`, and RuView is routinely
reached over plain HTTP on a LAN.

So both credential paths now accept only when EXACTLY ONE candidate verifies.
An attacker can still cause a refusal by planting a second valid cookie — a
nuisance — but no longer a takeover. Planting junk changes nothing, so this
does not become a trivial DoS.

Tests: +1 jwks (26-vs-1 fetch amplification), +4 step-up, +4 shadowing, +1
duplicate-name reader. Mutation-verified: reverting the stale-path guard gives
26 fetches; reverting to first-match cookie reads fails
`a_shadowing_cookie_cannot_silently_take_over_the_session`.

Verified: workspace 176 suites clean under CI flags, ruview-auth 62+25+2 with
--all-features, UI 22.

ADR-271: P1/P2/P3 marked RESOLVED with the analysis retained, since it explains
why each fix has the shape it does.

Co-Authored-By: Ruflo & AQE

docs/adr/ADR-271-cognitum-oauth-resource-server.md

@@ -235,13 +235,14 @@ shipped client** — no CLI subcommand, MCP server or Python client reads
 `~/.ruview/credentials.json`. The token is obtainable and verifiable; wiring the
 clients to send it is separate work.
 
-## Open problems and proposed remediation
+## Open problems — RESOLVED 2026-07-23
 
-Two findings from the 2026-07-23 adversarial review are **not fixed in this
-work**. Both are recorded here with a proposed design rather than patched in a
-hurry, because each changes a runtime property that deserves its own decision.
+Three findings from the 2026-07-23 adversarial review. All three are now
+**fixed**; the analysis is retained because it explains why each fix has the
+shape it does, and each is guarded by a test that was confirmed to fail against
+the old behaviour.
 
-### P1 — the JWKS fetch blocks a tokio worker, and the stale path is unbounded
+### P1 — the JWKS fetch blocks a tokio worker, and the stale path is unbounded — **FIXED**
 
 `verify.rs:182` calls `JwksCache::decoding_key_for`, which performs a blocking
 `ureq` request (`jwks.rs:181`, 3s connect + 3s read) directly on the async
@@ -283,7 +284,7 @@ asserting that a second concurrent verification is not serialised behind it —
 the current suite is entirely single-threaded and could not observe a
 reintroduction (`jwks::tests` contains no concurrency primitive at all).
 
-### P2 — a 15-minute access token becomes a 12-hour session
+### P2 — a 15-minute access token becomes a 12-hour session — **FIXED**
 
 `issue()` sets `exp: now() + SESSION_TTL_SECS` with `SESSION_TTL_SECS = 12 *
 3600`, deliberately not inheriting the access token's ~15-minute lifetime. The
@@ -314,7 +315,7 @@ worth it if RuView later needs true cross-device sign-out.
 Whichever is chosen, `SESSION_TTL_SECS` should be pinned by a test asserting the
 issued cookie's `Max-Age` matches the session's `exp`, so the two cannot drift.
 
-### P3 — dropping `__Host-` costs cookie origin-integrity, not just `Secure`
+### P3 — dropping `__Host-` costs cookie origin-integrity, not just `Secure` — **FIXED**
 
 The decision above frames omitting `__Host-` as trading away a `Secure`
 requirement that RuView cannot meet on a plain-HTTP LAN. That framing is