pup auth: OAuth client cannot request `dora_metrics_read` scope (rejected as unknown) — DORA read API returns 403

[aaron-junot]

Summary

pup's OAuth2 client registration does not include dora_metrics_read in its requestable scope set. As a result, a pup token can never carry DORA read permission, and all DORA read API calls return 403 Forbidden — even for users whose Datadog org role grants "DORA Metrics Read". Note dora_metrics_write IS in pup's scope set (confirmed via pup auth status); only read is missing.

Environment

• pup version: 1.0.0
• Site: datadoghq.com
• Auth: OAuth2 Bearer token (macOS keychain)

Reproduction

1. pup auth login (default scopes) → resulting token includes dora_metrics_write but NOT dora_metrics_read (the default ~97-scope request omits it). Confirm via pup auth status.
2. Attempt to add it explicitly: pup auth login --scopes dora_metrics_read →

   ⚠️  Unknown scope ignored: dora_metrics_read
   🔑 Requesting 0 scope(s):
   Error: OAuth error: invalid_scope: The following scopes are not recognized:
   

   pup treats dora_metrics_read as an unknown scope and strips it, so --scopes cannot request it.
3. Call the DORA read API with a valid pup token, e.g. POST /api/v2/dora/deployments (the list endpoint) →

   HTTP/1.1 403 Forbidden
   {"errors":["Forbidden","Failed permission authorization checks"]}
   

Expected Behavior

dora_metrics_read should be a recognized pup OAuth scope — ideally included in the default requested set (it is the read complement of the already-included dora_metrics_write), or at minimum requestable via --scopes dora_metrics_read without being stripped as "unknown".

Impact

Cannot programmatically read DORA deployments/failures via pup even when the authenticating user's role permits it. Blocks scripted verification of DORA metrics (Change Failure Rate / MTTR / Deployment Frequency) and any read-back after dora_metrics_write operations. Current workaround is UI-only read or falling back to a raw API/app-key with the scope.