Queue-based CRL invalidation — close the 5-minute revocation window

[vrknetha]

Problem

When an agent is revoked, proxies don't know until their next CRL poll (every 5 minutes, configured via CRL_REFRESH_INTERVAL_MS). During that window, the revoked agent can still send messages.

Current Flow

1. Registry revokes agent → adds to CRL in D1
2. Proxies poll /v1/crl every 5 minutes
3. Proxy refreshes local CRL cache
4. Next request from revoked agent gets rejected

Gap: Up to 5 minutes of continued access after revocation.

Proposed Flow

1. Registry revokes agent → writes to D1 + publishes agent.auth.revoked to Queue (already does this)
2. New Queue consumer on the proxy Worker receives the event
3. Proxy invalidates CRL cache immediately → fetches fresh CRL or directly marks the agent ID as revoked
4. Next request from revoked agent gets rejected within seconds

Architecture

• Registry already publishes agent.auth.revoked events to clawdentity-events Queue
• Add a Queue consumer binding on the proxy Worker
• Consumer receives revocation event → calls crlCache.invalidate() or directly adds the agent JTI to a revoked set
• Keep polling as fallback (in case Queue delivery fails)
• Connector is NOT involved — this is entirely proxy-side

Implementation

• Add Queue consumer binding to proxy wrangler.jsonc (production env)
• Implement queue() handler in proxy worker
• On agent.auth.revoked event: invalidate CRL cache for that agent
• Keep existing CRL polling as safety net (increase interval to 15-30 min since Queue handles the fast path)

Impact

• Revocation window: ~5 minutes → ~seconds
• Free plan: 10K Queue ops/day (more than enough for revocations)
• No changes to connector or CLI