Caveat evaluation failed error indistinguishable from denial in SpiceDB metrics

Context

SpiceDB's CheckPermission gRPC endpoint returns a caveat evaluation failed error when required context variables are missing from the request. This error surfaces as a permission denial to callers, but the underlying cause—missing caveat context—differs semantically from an explicit policy denial.

Problem

Default Prometheus metrics exposed by SpiceDB do not distinguish between caveat evaluation failures and legitimate authorization denials. Both paths increment the same denial counters, making it impossible to alert on missing context variables without custom instrumentation. This creates a blind spot: client bugs that omit required caveat parameters appear identical to correct policy decisions, delaying detection of integration issues.

Constraints

The schema defines caveats with required context variables, but the API does not enforce their presence at write time. Validation occurs only during CheckPermission evaluation. Metrics labels currently include permission and object_type but no caveat-specific dimension.

What is the recommended approach to surface caveat evaluation failures as a distinct metric dimension without modifying SpiceDB core? Can existing gRPC interceptors or middleware capture the error detail before it is normalized to a denial response? Are there plans to add a caveat_evaluation_failed counter or label in a future release?