OAuth client missing logs-config scopes — `pup api v1/logs/config/pipelines` always 401 with `logs_read_config` granted

[naofumi-fujii]

Is your feature request related to a problem?

Under OAuth (pup auth login), every Logs config endpoint gated by logs_read_config returns 401 Unauthorized, even on a freshly re-authenticated session whose token already carries logs_read_config (verified in pup auth status):

HTTP 401 Unauthorized: {"errors":["Unauthorized"]}

Sibling Logs config endpoints gated by other scopes work fine on the same token, so this is specific to the logs_read_config-gated family (pipelines, restriction queries), not to Logs config or OAuth in general.

This is the Logs-config analogue of #437 / #443 (AWS / GCP cloud-configuration scopes) and #445 / #570 (DBM built_in_features): the scope appears in the granted token but the server-side OAuth client is not actually authorized for it.

Repro

$ pup --version
pup 1.2.0

$ pup auth login   # standard interactive flow, defaults
$ pup auth status | jq '.scopes | length'
100
$ pup auth status | jq '.scopes | index("logs_read_config")'   # scope IS granted
<non-null index>

# logs_read_config-gated endpoints -> 401
$ pup api v1/logs/config/pipelines
Error: HTTP 401 https://api.datadoghq.com/api/v1/logs/config/pipelines: {"errors":["Unauthorized"]}

$ pup api v2/logs/config/restriction_queries
Error: HTTP 401 https://api.datadoghq.com/api/v2/logs/config/restriction_queries: {"errors":["Unauthorized"]}

# sibling Logs config endpoints gated by OTHER scopes work on the same token
$ pup api v2/logs/config/archives    # logs_read_archives  -> 200
$ pup api v1/logs/config/indexes     # logs_modify_indexes -> 200

So logs_read_config is present in the token yet does not actually authorize the endpoints it is supposed to gate, while logs_read_archives / logs_modify_indexes work as expected.

Also missing: logs_write_pipelines

My end goal is to add a GeoIP Parser processor to a logs pipeline from pup (to enrich request logs with the requester's country). That requires the write scope logs_write_pipelines, which is not in default_scopes() / all_known_scopes() in src/auth/types.rs at all.

Per the precedent in #445, simply adding a not-yet-server-enabled scope to default_scopes() and re-running pup auth login --scopes ... fails with OAuth error: invalid_scope, so this needs server-side enablement on the pup OAuth client before a client-side PR is useful.

Request

1. Enable the logs_read_config scope server-side for the pup OAuth client so the already-granted scope actually authorizes v1/logs/config/pipelines and v2/logs/config/restriction_queries (mirroring the OAuth client missing AWS / GCP cloud-configuration scopes — pup cloud {aws,gcp} list always 401 #437 / OAuth client missing DBM scope — pup dbm samples search always 403 with built_in_features #445 fixes).
2. Enable logs_write_pipelines so pipelines can be created/updated over OAuth.

Once enabled server-side, I'm happy to follow up with a client-side PR adding a pup logs pipelines list/get/create/update command (modeled on the existing archives / restriction-queries subcommands) and the corresponding scopes — same shape as #443 / #570.

Use case

OAuth-only orgs (SSO, no long-lived application keys) cannot fall back to DD_API_KEY / DD_APP_KEY, so logs pipeline configuration (e.g. adding a GeoIP processor) is currently impossible from pup.