refactor(switch): forward the forge CLI's own error text

[max-sixty]

Follow-up to #3600, independent of it (no shared files).

GitHub and GitLab rewrote forge API failures into messages of our own, discarding what the CLI said. GitLab picked its three by prose — error_text.starts_with("404") — the pattern #3595/#3597 removed elsewhere.

Before / after

A GitLab MR that doesn't exist:

- ✗ MR !9999 not found
+ ✗ glab api failed for MR !9999
+ ▎ glab: 404 Not found (HTTP 404)

A GitHub PR that doesn't exist — the one message kept, now with gh's verdict under it rather than instead of it:

  ✗ PR #999999 not found on max-sixty/worktrunk (gh default). Check that `gh repo set-default` points to the correct repository.
+ ▎ gh: Not Found (HTTP 404)

The rule, now written down

src/git/remote_ref/mod.rs gets an Error Messages section: forward the CLI's own line, and write our own only where the CLI structurally cannot report the condition. Two cases qualify — GitHub's 404 (it answers about an owner/repo we chose, from gh repo set-default or a remote; gh can't know that) and Azure's missing azure-devops extension (a precondition az extension list answers, which az never names). Reading more nicely than the CLI doesn't qualify.

cli_api_error and cli_api_error_details gained docstrings for the mechanism: our context as the headline, the CLI's words in the gutter, so a provider with something to add passes it as message rather than bailing.

Evidence

Measured, not assumed — both CLIs render an API failure the same way:

	stdout	stderr
gh api …/pulls/999999	{"message":"Not Found",…,"status":"404"}	gh: Not Found (HTTP 404)
glab api …/merge_requests/…	{"message":"401 Unauthorized"}	glab: 401 Unauthorized (HTTP 401)

cli_api_error_details prefers stderr, so the gutter gets the human line, not the JSON. That also surfaced a test bug: the glab mocks never set stderr, so they'd have enshrined output real glab doesn't produce. Fixed to match the probe.

gh puts the status in a structured field, so its 404 arm keys on status. glab puts it only inside the message text — nothing to key on, which is why prose-matching was the only way to keep those arms.

What this gives up

A bad or expired token no longer gets "run gh auth login" / "run glab auth login"; it gets gh: Bad credentials (HTTP 401). The far more common case — no auth configured at all — is unaffected: gh prints its own "please run: gh auth login" and always did fall through to forwarding. Happy to restore the GitHub 401 arm (it's structurally keyable); GitLab's can't come back without prose-matching.

Testing

cargo run -- hook pre-merge --yes → 4572 passed. Six snapshots reviewed individually before accepting (five updated, one new). Both paths also driven through the real gh binary (a live 404 and a live 401), not only mocks. Clippy clean with --features shell-integration-tests.

Coverage: the GitHub 404 arm and the forwarding fallthrough each have a test, on both forges. codecov/patch also flagged one line — re-indenting the 404 block pulled a pre-existing gap into the patch, and it turned out to be real: the gh repo set-default half of the hint, the fork workflow the message exists for, had never been tested. test_switch_pr_not_found_gh_default closes it.

This was written by Claude Code on behalf of Maximilian Roos