Keep a raised user-verification demand across a Burrow restart

[nedtwigg]

Hardening for the user-verification demand a Relay raises after enrollment.

When an operator turns DORMOUSE_REQUIRE_USER_VERIFICATION on after a computer enrolled, the Relay says so in its policy frame and the Burrow service saves the raise onto the stored enrollment. If that save failed (a locked keychain or SecretStorage, a disk error), the raise was dropped: the running Burrow kept enforcing it, but the next start reloaded the enrollment from the store and ran at user presence unless the Relay repeated the frame.

• #persistRaisedPolicy in lib/src/host/remote/service.ts now puts the raise on the in-memory #enrollment before it saves, and keeps it there when the save fails.
• #startBurrow applies a held raise to the enrollment it starts whenever the stored copy lacks it (same burrowToken), and retries the save then.

So a restart in the same process — a network-policy change, a reconnect — always starts raised, and only the Relay's frame or a re-enrollment changes the demand. What remains is a full relaunch while the store keeps failing to save; that is now stated under "Known gaps".

Tests

lib/src/host/remote/service.test.ts → "pairing queue" → "keeps a raised UV demand across a restart when the store could not save it": the save fails when the Relay raises; after the store recovers and the Burrow restarts with a Relay that never repeats the frame, the start has saved the raise, and a presence-only passkey never reaches the pairing modal. Both assertions go red with the service change reverted.

Specs

• docs/specs/security-remote.md → "Trust boundary": S181 widened so that no restart lowers the demand either, naming BurrowService (rationale extended; word budget ratcheted to 7100).
• docs/specs/remote-security-model.md → "Passkeys": a raise outlives a restart even when it could not be saved.
• docs/specs/security.md → "Known gaps": the relaunch-with-a-failing-store residual (word budget ratcheted to 2650).
• New canary seed .github/audit/canaries/uv-raise-lost-on-restart.patch (Rule: S181).

This PR touches .github/, so the owner merges it.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	5dcc523
Status:	✅  Deploy successful!
Preview URL:	https://03b92316.mouseterm.pages.dev
Branch Preview URL:	https://burrow-uv-raise-sticky.mouseterm.pages.dev

View logs

[dormouse-bot]

The service change and its spec edits read correct; approval is withheld only because Workflow Lint is red on this head. That failure isn't from this PR: zizmor flags swatinem/rust-cache@6323deb… # v2 in .github/workflows/ci.yml (the v2 tag now points at d1527c8f67ef), and main's latest CI run 39445113310 fails the same way. Every other check passes.