Enforce fine-grained CloudEvent grants

[elffjs]

Context

dq is a fusion of telemetry-api and fetch-api. telemetry-api could honor a narrow cloud_events JWT grant — authorizing specific event types, from specific sources, optionally pinned to specific IDs, rather than coarse "read all cloud events." fetch-api never had this, and the merged service inherited fetch-api's coarse-only check. The cloud_events grant already arrived in context but was never consulted.

This restores the capability. It's security-sensitive — the default is fail-closed.

Approach

Two independent authorization paths for the CloudEvent queries (cloudEvents, latestCloudEvent, availableCloudEventTypes), OR'd together — a request is allowed if either applies:

1. Full access via permissions — GetRawData, or the GetLocationHistory + GetNonLocationHistory combo. Reads all of the subject's events (unchanged behavior).
2. A scoped cloud_events grant — evaluated independently of the permissions enum; the grant is self-authorizing.

Enforcement is up-front and fail-closed (cloudEventRequestAllowed / grantCovers, ported from telemetry-api's validCloudEventRequest): a request is authorized only if its filter falls entirely within a single grant. Unset filter dimensions default to the * wildcard, so a narrow grant requires the caller to scope their query to match it. We validate rather than post-filter results — a request that can't be fully served is rejected, not partially serviced. Subject-DID scoping still applies in both paths.

AdvancedSearchOptions AND's its top-level fields and only OR's within a single field, so the OR-of-ANDs grant model can't be losslessly pushed into one query — validating the request (gate, don't rewrite) is the clean fit.

Scope

• Single chokepoint requireSubjectOptsByDID covers all three resolvers and the MCP surface (same resolvers via @mcpTool). No resolver changes needed.
• No JWT/middleware changes — grants already deserialize into DQClaim → tokenclaims.Token.CloudEvents.

Out of scope

• The internal gRPC FetchService remains an unauthenticated, network-isolated, trusted surface by design — grants are not enforced there.
• Grant tags are not checked (no tags field on CloudEventFilter; telemetry-api ignored them too).
• Multi-ID grants are usable one ID per query (parity with telemetry-api). Could later inject grant-derived id IN (...) when the caller under-specifies — deferred.

Changes

• internal/graph/auth_helpers.go — replace requireRawDataToken with hasFullCloudEventAccess + cloudEventRequestAllowed / grantCovers, wired into requireSubjectOptsByDID.
• internal/graph/cloud_events_auth_test.go (new) — 22 table-driven cases (wildcard / narrow / specific-ID grants, plural types, full-access bypass, grant-only access, subject mismatch).
• README.md, MERGER_REVIEW.md — document the two-path model and the gRPC out-of-scope decision.

Verification

go build ./..., go vet ./internal/graph/, go test ./internal/graph/ all pass.

🤖 Generated with Claude Code