feat(sdk): rate-limit counters can live somewhere shared

[cport1]

Closes #726. Stacked on #28 (typed decision) — the NOT_RUN state it reports comes from there.

The bug

rate-limit-rule.ts:19 hard-constructed new InMemoryRateLimiter() — a Map, with no seam to replace it. On any deployment with more than one process the limit is effectively max × instances, and on Vercel or Lambda it also resets on every cold start. rateLimit({ max: 100, window: 60 }) across eight replicas is an 800/min limit that an autoscaler can raise for you.

This was inconsistent with the rest of the SDK: detection/stores.ts and the captcha's challenge and token stores were already behind swappable interfaces with in-memory defaults. The one piece of state that actually has to be shared was the only one that could not be.

The sync/async problem

Rule.evaluate() is synchronous. Making it async would turn every rule evaluation into a promise for the sake of the one rule that might need it, and the in-memory path — which is most installs — would pay for a network store nobody configured.

So a store declares which it is:

• Sync store → consumed inline during evaluate(). The default in-memory path, unchanged and allocation-free.
• Async store → consumed in a new optional Rule.prepare(context), which protect() awaits before evaluation. This is the pre-fetch pattern the SDK already uses for IP enrichment and Web Bot Auth verdicts, so it fits the existing architecture rather than inventing a second one.

A rule whose async store was never prepared reports NOT_RUN, not ALLOW. The synchronous evaluateRules() cannot consume a networked store, and a rate limiter that has quietly stopped limiting is indistinguishable from one that is working — that is the failure mode worth being loud about.

The Upstash store

Ships in the core package, not a sixth workspace, and calls the REST API with fetch rather than depending on @upstash/redis. Two commands in a pipeline is not worth a dependency, a version to track, or a transitive node: import finding its way into an edge bundle. check:edge covers it automatically.

Upstash is the right first target because it speaks Redis over HTTP: Vercel Edge, Workers and Deno have no node:net, so an ordinary Redis client cannot open a socket in exactly the serverless deployments that need shared counters most.

Two details worth reviewing:

• Fixed window puts the window id in the key (wd:rl:f:<key>:<windowStart>), so expiry is the only cleanup needed and two processes cannot disagree about which window they are in. EXPIRE … NX, or a long window gets extended into a sliding one by later requests.
• Sliding window gives each request a random member suffix (<now>-<rand>). Two requests in the same millisecond would otherwise be one ZADD that overwrites rather than two that count — undercounting exactly when the limit matters.

Fails open by default when Redis is unreachable, because a rate limiter that takes the site down when its datastore has a bad minute has done more damage than the traffic it was shaping. onError: 'closed' for limits protecting something more expensive than availability. Either way the outcome lands in decision.results rather than looking like a normal evaluation.

Verification

14 new tests, 341 total. The one that matters: two WebDecoy instances pointed at one store enforce max: 2 as two, where before each had its own Map and it was four. Also asserts exactly one consume() per request — a second consume in evaluate() after prepare() would double-count and halve every limit. Build, lint and check:edge green.