[Feature Request] Surface upload rejection reasons when CLI returns success but no report lands

[Kobby-Bawuah]

What product do you want to improve?
Codecov CLI / Upload pipeline

Is your feature request related to a problem? Please describe.
The Codecov CLI can return a successful response while the upload actually fails on our backend, with no error or reason surfaced to the user. This forces customers into hours of blind trial-and-error. We've seen this manifest in at least two concrete ways:

1. CLI returns 200 with error=None, warnings=[] but the upload never lands on the commit page. This happens when fields like the upload name (-n flag) exceed length limits or contain unsupported characters. The upload appears successful to the user but is silently dropped post-acceptance, with no error in the UI either.

2. CLI prints a "queued for processing" success message containing a result URL that does not match where it actually POSTed. For example, the CLI can tell the user results will be available at app.codecov.io/github/<expected-org>/<repo>/commit/<sha> while actually POSTing to <different-org>/<repo> (because the slug auto-resolved from a fork's origin remote, even though the rest of the CLI output was consistent with the expected org). The backend returns a 400 Bad Request, but the CLI surfaces "Upload queued for processing complete."

In both cases the user is told the upload succeeded, has no way to see the actual failure, and the UI shows nothing — leading to hours of guessing at the problem.

Describe the solution you'd like

• Surface rejection reasons in the CLI response (or via a status field the CLI can poll) when an upload is accepted but later dropped during processing.
• Validate critical fields (e.g. name length / character constraints) at submission time and return them as actionable errors instead of silently dropping.
• When the CLI receives a non-2xx response from the API, propagate it clearly to the user instead of printing a generic success message.
• Make the success message's "results will be available at" URL reflect the actual slug the CLI used to POST, not just the slug the user might have expected.
• Make any post-acceptance rejection visible somewhere in the Codecov UI on the affected commit page (or surface it via a queryable status endpoint).

Describe alternatives you've considered

• Polling the repos_commits_retrieve API after upload (works but requires bespoke client logic and doesn't surface the underlying reason).
• Using fail_ci_if_error: true (only catches CLI-level errors, not post-acceptance rejections).

Additional context

Hit by multiple customers trialing Codecov. In one case, the user lost ~a day debugging blindly before discovering shortening the -n value made uploads work. In another, a user spent significant time confused about why uploads weren't appearing for the expected repo, eventually tracing it to the CLI auto-detecting the slug from a fork's origin remote while still printing a "results will be at " URL. The lack of error propagation is a significant friction point for adoption.

[linear]

CCMRG-2222