WARDEN-WP-0033-T05: split the stale cadences, and record how a blocker was verified

The 90-day --stale-days default on `warden route gaps` was not a loose threshold,
it was an inert one: the delegation register was created 2026-08-15, so it could
not have fired before November. It was inherited from the catalog pointer cadence
and applied to a claim with a completely different half-life.

Two changes. DEFAULT_BLOCKER_STALE_DAYS = 14 now governs interim blockers, while
DEFAULT_STALE_DAYS = 90 keeps governing pointer freshness -- "is this the right
owner and page" is quarterly, "has the owner answered" is not. 14 is calibrated
on blockers that actually cost something: ten days for the secrets-engine lanes,
one for RISK-F-0001, roughly fifty for FLEX-WP-0007.

The second change matters more. `reviewed` records when someone touched an entry,
which is indistinguishable from re-checking it -- six lanes read as freshly
reviewed today because I typed in them. `verified:` now says how the claim was
established, and asked-and-waiting explicitly does NOT count: that is the state
the secrets-engine blocker sat in for ten days while looking current. A lane in
that state is stale at zero days old, and key-cape-oidc-login proves it works.

8 of 14 interim lanes are honestly marked unverified rather than given a fresh
date they did not earn.

--fail-on-stale exits 3 for a cron or gate. No CI test on age: a date-triggered
failure breaks the build for whoever commits next instead of whoever owns the
blocker. The CI test is structural -- every interim lane must record how it was
verified -- so it fails on the commit that introduces the omission.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

workplans/WARDEN-WP-0033-native-lane-handoff.md

@@ -194,6 +194,51 @@ avoid is the 2026-08-17 one recorded in `.claude/rules/finding-routing.md`:
 ops-warden answered a question well and never routed it, and another repo ended
 up filing it.
 
+```task
+id: WARDEN-WP-0033-T05
+status: done
+priority: medium
+```
+
+**Make blocker staleness a mechanism instead of an intention.**
+
+Four stale blockers surfaced in twelve hours: an OpenBao token recorded expired
+that was valid, a verification script recorded ready that had never been written,
+a ten-day `secrets-engine` question answerable from their source, and
+`FLEX-WP-0007` cited as blocking `policy.enabled` seven weeks after it read
+`finished`. `.claude/rules/finding-routing.md` has said *re-read a blocker before
+trusting it* since `RISK-F-0001`. Saying it has not worked.
+
+`warden route gaps` had a `--stale-days` threshold defaulting to 90, which was
+not loose but **inert** — the register was created 2026-08-15, so it could not
+fire before November.
+
+**Done 2026-08-21.** Two changes, and the second matters more:
+
+1. **Split the cadences.** `DEFAULT_STALE_DAYS` (90) still governs pointer
+   freshness — "is this the right owner and page" genuinely is quarterly. New
+   `DEFAULT_BLOCKER_STALE_DAYS` (14) governs interim blockers, calibrated on the
+   cases that cost something: ten days for the secrets-engine lanes, one day for
+   `RISK-F-0001`, ~50 for `FLEX-WP-0007`. At ~15 lanes it surfaces about one a
+   day rather than a wall, and it fires on zero lanes on age today.
+
+2. **`verified:` distinguishes re-checking from re-editing.** `reviewed` records
+   when someone touched the entry; nothing recorded whether the claim was
+   re-established. `owner-confirmed` and `source-read` count;
+   **`asked-and-waiting` and `unverified` do not**, and a lane in those states is
+   stale regardless of its date. `key-cape-oidc-login` is the proof: asked today,
+   zero days old, correctly flagged.
+
+Current state: 14 non-draft interim lanes — 5 `owner-confirmed`, 1
+`asked-and-waiting`, 8 `unverified`. The 8 are honest; they were carried forward
+this session without a check and now say so instead of hiding behind a fresh date.
+
+`--fail-on-stale` exits 3 so a cron job or gate can act. **Deliberately not a CI
+test on age**: a date-triggered failure breaks the build on a calendar day with
+no code change, punishing whoever commits next rather than whoever owns the
+blocker. The CI test is structural instead — every interim lane must record
+*how* it was verified, which fails on the commit that introduces the omission.
+
 ## Related
 
 - `secrets-engine` `SECRETS-WP-0006` — catalog admission, decision `ae676382`