Add mapbox feedback list/get

[mattpodwysocki]

What

mapbox feedback list/get: the feedback end users submit from apps built with Mapbox, filterable by id, status, category, a free-text search phrase, trace id, or a time window; sortable; paginated. Hand-authored into custom-openapi/, like search, since openapi-specs has no spec for this API.

feedback create is declared in the spec but never reaches the command surface. Confirmed directly against production: a POST /oauth/register requesting user-feedback:write silently drops it from the granted scope, the same unregistrable shape UNSUPPORTED_OPERATIONS already documents for accounts create-token/update-token/delete-token. No mapbox auth login token can ever carry it.

Based directly on main; it no longer depends on #43/#44/#45/#48.

Worth a reviewer's eye

Naming the disabled operation. It's createFeedbackItem rather than create: the withheld-operation guard in generate_skills.rs checks the bare command word against every generated file's text, and a bare create collides with the unrelated styles create. Caught by that guard failing, not by inspection.

Each filter takes one value for now. The API takes several values only as a repeated parameter (status=a&status=b); the command builder can't repeat a query parameter yet, so multi-value filters are left for a separate PR.

Verification

Smoke-tested against production: list with single-value --status/--category filters, --order and the pagination cursor, and get by id, both return the documented shape. create is absent from --help and errors as an unrecognized subcommand rather than reaching the API.

693 tests, cargo fmt and cargo clippy --all-targets -- -D warnings clean.

🤖 Generated with Claude Code

[mattpodwysocki]

On creating feedback: this hit the same registration wall other disabled operations here already document (tokens:write, fonts:metadata) and that's been raised with the owning team before. A POST /oauth/register for user-feedback:write silently drops it the same way, so no mapbox auth login token can ever carry it, confirmed directly against production. The actual next step for create isn't a CLI design question, it's asking identity-and-auth whether that scope can be added to the registration allowlist. Once (if) that happens, enabling the command here is small: drop the UNSUPPORTED_OPERATIONS row and it reaches the command surface the same way list/get already do.

[zmofei]

@mattpodwysocki Heads-up: I retargeted this PR to main and rebased it down to just the feedback commit, so it no longer depends on #43/#44/#45/#48. I need to build other stacked PRs on top of it.

I also reviewed it against the Feedback API docs and the live API, and pushed fixes (still one commit, f5863c9):

• Multi-value filters didn't work. The API only takes several values as a repeated parameter (status=a&status=b). A comma-separated value got a 400 for --status received,reviewed, and silently returned 0 items for --feedback-id and --category. The flags can't be repeated either, since the command builder has no repeatable query parameter. Each filter now documents a single value; proper multi-value support should be its own PR, since it touches the shared builder.
• Default order. order defaults to asc, so the default is oldest received first, not newest.
• Wording. Aligned the service description and --created-* with the docs (end-user feedback from the Feedback Agent).

693 tests, fmt and clippy clean; single-value filters, --order and get re-checked against production.

I've approved, but since I also committed to this PR, it may need an approval from another owner too — could you find one?