Adaptive per-origin action pacing (ANTI-BOT-POSTURE Option 0 resolution)

Problem

The web actor can trigger a site's velocity or challenge controls by performing write actions too quickly. The response must be enforced by trusted code, learned per site, and limited to the affected origin.

PR #218 is a draft prerequisite. It contains an unwired pure reducer and tests. It does not change extension behavior.

Decisions

• Start with no pacing rule for any site.
• Key every rule by exact canonical origin.
• Learn only from trusted fixed classifiers. HTTP status and Retry-After metadata may be inputs. Structural challenge detection may be an input. Arbitrary page text is not an input.
• Keep the controller, history, and persistence in the service worker. Use one serialized lane per origin across all sessions.
• Version and validate persisted records. Reads may continue if pacing storage is unavailable, but browser write actions fail closed.
• Pace browser write actions only. Natural elapsed time counts toward the interval.
• Race every wait against Stop, abort, and the dispatch deadline. Recheck the origin, tab, policy, and action authority after the wait.
• Use a one-action probe for descent. Reserve the action before dispatch, observe its trusted result, wait through the probe window and settle period, then adopt a lower interval only if the result stayed clean.
• At the ceiling, return a trusted terminal handoff. Do not execute the action, retry it, or delegate around the policy.
• Do not add a model-facing rule tool in the first usable version. Routine waits and rule history stay out of model context.
• Show users a live fixed status while waiting, with an accessible Stop control.
• Add a human-only Paced sites settings list with individual forget controls and audit events.
• Keep the existing rejects: no fingerprint spoofing, proxies, or challenge solvers.

Required integration

• Trusted persistence and hydration.
• Pre-action and post-action hooks for every browser write path, including page code and site client relays.
• Fixed signal classifiers and hidden trusted result metadata.
• Cancellation and liveness propagation through bound actors and relays.
• Typed terminal handoff that replaces any actor-written summary.
• Settings, activity, wait status, accessibility, and Stop behavior.
• Unit, browser, E2E, and visual coverage.

Acceptance cases

• Concurrent sessions on one origin cannot pass the limiter together.
• Service-worker restart preserves the rule and cadence state needed for safe enforcement.
• Unreadable pacing state cannot authorize a write.
• Stop during a wait prevents the delayed action.
• Navigation, tab closure, deadline expiry, or authority changes during a wait prevent the action.
• A page cannot create a pacing signal with ordinary text or clear a rule through model instructions.
• A ceiling handoff cannot be retried or delegated automatically.
• The wait and settings surfaces are usable by keyboard and assistive technology.

Tune constants through code, tests, the eval harness, and field reports. Do not copy live values into this issue.

Start with draft PR #218, especially its unwired pure reducer and tests, then map the required service-worker, browser write-path, relay, settings, and wait-status integrations. Use the listed unit, browser, E2E, and visual coverage as the verification plan; done means the acceptance cases hold, including fail-closed writes, cancellation, per-origin serialization, terminal handoff, and accessible controls.