fix(cli): give an edge mitigation its own code instead of FORBIDDEN

[yashau]

Why

Found while running prk login from an Ubuntu server. Cloudflare challenged the request, and prk reported it accurately — then told the reader to go and fix the wrong system:

error: Cloudflare intercepted this request with a `challenge` mitigation, so it never reached the server
  help: An administrator must grant your identity a role on this scope. `prk whoami` shows the identity the server sees.

The message was right all along; only the next step was wrong. cf_mitigated responses were classified as ErrorKind::Forbidden, so they inherited its hint and sent you to audit a grant table that was working fine, in a different product, with nothing to find.

Sharing a kind was tempting because the two are genuinely the same status — both arrive as a bare 403, which is why the mitigation is read off cf-mitigated rather than the status in the first place. But their fixes have nothing in common: FORBIDDEN wants a grant, and no grant will ever clear a bot rule.

Same shape as 2ed6b02, which gave a guard refusal its own code instead of reusing LAUNCH_FAILED.

The new kind

	Before	After
Code	FORBIDDEN	MITIGATED
Exit	4 (not authorized)	7 (cannot reach the server)
Hint	grant advice	names the WAF rule, and the Bot Fight Mode caveat
Retryable	no	no

Exit 7, not a new number: the request never reached the origin, which is already what 7 means for UNREACHABLE, TLS_FAILURE, TIMEOUT and NOT_A_PRICK_SERVER — and the exit table is part of the CLI's contract. Deliberately not retryable, unlike Unreachable and Timeout, because the identical request gets challenged identically until something changes at the edge.

Two tests had pinned the old behaviour

One of them end to end through the real client. The unit test asserted only that the message named the mitigation, which held just as well while the kind was wrong — the assertion that would have caught this is the one nobody wrote. Both now assert the kind.

Docs

Nothing in docs/ mentioned the bot layer at all before this. The new Cloudflare protections guide covers why this hits servers and CI runners but not laptops, and states two things outright:

• Bot Fight Mode cannot be skipped by a custom rule. It doesn't run on the Ruleset Engine, so Skip/Bypass/Allow have no effect — the obvious fix silently does nothing on a free plan. Super Bot Fight Mode is the one that supports a skip rule.
• Skip the bot product, not the whole WAF. The Worker implements no rate limiting; per the threat model, Cloudflare's edge is the entire denial-of-service story for a prick deployment.

It also answers the question a reader will have — no, an exception doesn't weaken the authorization model, because Access still runs and the bot layer was never the gate.

The Actions guide gets a note in "The first run will 403, and that is the flow": GitHub-hosted runners are datacenter IPs, so the confusable failure is now documented right next to the expected one.

Verification

• 649 Rust tests pass; lint:rust (clippy -D warnings) green — it caught the first version of the exit-code arm under match_same_arms
• astro check on the docs: 0 errors, 0 warnings, 0 hints
• fmt:check, lint:typos, lint:loc green
• pre-push gate (typecheck, clippy, rust + js tests) green

Not verified against a live challenge: the fix was derived from the cf-mitigated header contract and exercised through the mock in tests/responses.rs, not by provoking a real Cloudflare challenge.

🤖 Generated with Claude Code