[FEATURE] Expose response headers (esp. X-RateLimit-* metadata) on typed subcommands

[rpdids]

Is your feature request related to a problem?

The typed subcommands (monitors list, logs list, slos status, dashboards get, metrics query, …) don't expose the HTTP response headers. Datadog returns rate-limit information in the X-RateLimit-* response headers on these endpoints, but the typed commands discard it.

This matters most on a 429: when a typed command is throttled there's no way to see which rate-limit rule was hit, its ceiling, or how much budget remained — that information is only in the response headers, and the header-printing flags exist solely on pup api, not on the typed commands. Verified on the latest release, v1.12.0:

$ pup monitors list --include
error: unexpected argument '--include' found

$ pup monitors list --verbose
error: unexpected argument '--verbose' found

monitors list --help shows no header/--include/--verbose/raw flag (only query-shaping options like --query, --tags, --limit, --output), and --output offers only json/table/yaml/csv — no way to surface response headers from a typed command. So anyone using the ergonomic typed commands (rather than raw pup api) is blind to the rate-limit rule that's throttling them.

Describe the solution you'd like

Make response headers reachable from the typed subcommands. Any of:

• Accept --include / --verbose on the typed subcommands (same semantics as on pup api), or
• A dedicated flag such as --show-headers / --response-headers, and/or
• At minimum, surface the X-RateLimit-* headers in the error output on a 429 / non-2xx, ideally as structured fields, so the throttling rule is diagnosable without a second call.

Describe alternatives you've considered

• A follow-up pup api <endpoint> --include call. Works, but requires mapping each typed command back to its raw endpoint; issues an extra request (added load); and because Datadog rate-limit rules are per-endpoint, that follow-up usually returns 200, so x-ratelimit-remaining is sampled after the throttling event rather than at the moment of the 429 — and for POST-search endpoints the GET sibling may name a neighbouring rule. It also downloads the full response body just to read a few headers.

• Bypassing pup with a direct HTTP call. Gives first-class access to response.headers, but loses pup's auth handling and the typed commands' query/time-window/storage-tier ergonomics.

Additional context

The X-RateLimit-* headers are present and useful — they're just only reachable via pup api today. Examples via the generic subcommand:

$ pup api v1/monitor --include
x-ratelimit-name: get_all_monitors
x-ratelimit-limit: 1000

$ pup api v1/slo --include
x-ratelimit-name: slo_get_all
x-ratelimit-limit: 1000

$ pup api v2/logs/events --include
x-ratelimit-name: logs_public_search_api
x-ratelimit-limit: 10

Context: we run automation on top of the typed commands and need to report which Datadog rate-limit rule is throttling us (we suspect a shared/org-wide bucket). The per-endpoint rule name is exactly the evidence we need, but it's unavailable from the commands we actually use.

Proposed command syntax (if applicable)

# print response headers alongside normal typed output
pup monitors list --include

# or a dedicated flag
pup logs list --query "service:x" --from 7d --show-headers

# at minimum: include X-RateLimit-* in the error when throttled
pup logs list --query "service:x"   # on 429, surface rule name / limit / remaining