[zmofei]

Adds mapbox report "<message>", which sends feedback about the CLI to the Feedback API's CLI endpoint. Stacked on #99.

• Feedback is filed under Mapbox's own account, so report is the CLI's request rather than the user's. It is the first entry in CLI_TOKEN_COMMANDS as Use::Preferred: it sends with the CLI's token and its Referer (see Fetch the CLI's token from cli.mapbox.com instead of building it in #99), and falls back to the user's token while the CLI's can't be used. The request then carries the user's token, but the message is still filed under Mapbox's account. A typed --token or --use-login sends with the user's token, and the CLI's is not tried. With no user token either, it fails with cli_token_unavailable or cli_token_forbidden, with a fix pointing at mapbox auth login or --token.
• The message goes out with the CLI's version and OS appended (— mapbox-cli <version> on <os>). The Feedback API has no field for them, so they go in the text, where --dry-run shows them.
• A command someone is waiting on is never paced. It uses the token on disk or fetches past any backoff, and a miss on that fetch is not counted, so report never lengthens telemetry's backoff. When report's request is refused (401/403), a fresh token is fetched and the message sent again if a different one comes back, unless this run just fetched it. A 429 on the CLI's token falls back to the user's token without being counted: every install shares that token, and a 429 was not acted on. The next run tries the CLI's token again, so a token republished or fixed in the Console works at once. Telemetry keeps Fetch the CLI's token from cli.mapbox.com instead of building it in #99's cooldown.
• Telemetry settings don't apply to report: the token is shared and public, and fetching it sends nothing about the user.
• The rules for sending with the CLI's token live in cli_token::send_with_cli_token, used by telemetry and commands alike; Disk::Background, Disk::Command and Disk::Unchecked hold where they differ.
• MAPBOX_CLI_TOKEN is tried first, sent once, and never checked, counted or replaced, as telemetry treats it. A resend doesn't ask for confirmation again, and a command on the list may not read its body from stdin (held by a test), since a resend couldn't read it twice.
• An empty or blank message is refused before sending. A message starting with - gets a tip that quotes it whole and says to put it after --.
• Under -o text, a successful report shows only that it was sent, the message and its id; -o json prints the answer whole. A dry run under -o text shows the body and which token it would use.

Testing: unit tests for send_with_cli_token against a fake ledger (a dead token replaced and resent, a command retrying after any refusal, the same token not resent, only a 2xx accepted), for which ledgers retry, for only a 429 falling back, for the version and OS suffix, and for the report rendering. End-to-end tests for what is decided before any request reaches Mapbox, through a dead proxy and a loopback token endpoint: no token at all (and the fix it gives), a typed --token outranking the CLI's, a cooldown not holding report back, report fetching through the backoff, an unreachable endpoint reported as such during a backoff, a command's miss leaving the backoff alone, the Referer going with the CLI's token but not the user's, a dry run planning with the user's token, the dry run's body and token under -o text, an empty message refused, and the tip for a message starting with -. Ran the end-to-end tests against the commit before each round of fixes and watched the new ones fail. Posted to the real endpoint with curl: the CLI's token answers 401 without its Referer and 200 with it; a user's token answers 200 with and without any user-feedback scope. Sent a real mapbox report on the CLI's token: 200, and the API kept the version and OS suffix. The Outputs in docs/commands.md are that send, shown both ways.

Not tested: a real 429 on the CLI's token, and a refused MAPBOX_CLI_TOKEN not being replaced end to end (no way to point the API at loopback; unit-tested only). A run on the CLI's token is not recorded as a token source in history or telemetry, which would need a new auth.source value.

[mattpodwysocki]

Read through this one and ran the tests locally, all green. What goes out is just the message and category, nothing from the environment, and a resend only follows a 401/403 so there's no double send. Mostly UX and wording inline. Two broader thoughts:

• Reports carry no CLI version or OS. The User-Agent has the version, but I doubt the Feedback API keeps it, so a "tilesets query hangs" report arrives with nothing to go on. Adding version and OS to the body (so --dry-run shows them) seems worth it.
• Only 401/403 fall back. Every install shares one token, so if the Feedback API rate-limits that account, everyone gets a 429 even though their own token would work. A 429 wasn't processed either, so falling back on it looks safe.

Small ones: an empty or whitespace-only message is accepted and sent, a message starting with - hits a usage error with no hint about --, and the two ids in the commands.md outputs table don't match.

[zmofei]

Thanks! Addressed in 9d0c15d.

• Version and OS are appended to the message (— mapbox-cli <version> on <os>), so --dry-run shows them. The Feedback API has no field for them, and I didn't check whether it keeps unknown fields, so they go in the text.
• A 429 on the CLI's token now falls back to the user's token. It doesn't count against the CLI's token. With no token of their own, the 429 is returned as is.
• An empty or blank message is refused before sending. A message starting with - gets a tip that quotes it whole and says to put it after --.

Not done yet: the ids in the commands.md outputs. They need a fresh live capture, which will also pick up the version suffix. I'll push that separately.

Tested: fmt, clippy and the full suite. The 5 new or changed end-to-end tests fail on 009a3b0. Not tested: a real send with the suffix, or a real 429 on the CLI's token.

[mattpodwysocki]

All addressed, thanks. The dry run showing the token and the full body is a nice improvement.