[BryanFRD]

Closes #1154. Follow-up to the review on #1152. The third point from that review, the probe now carrying security weight, is filed as #1153.

The Gitea fallback warning says it is push-only

On Gitea / Forgejo with only GITHUB_TOKEN, the push still falls back to it, but release creation reads GITEA_TOKEN / FORGEJO_TOKEN and is skipped (build_forge_instance returns None and the release block is an if let Some). The warning now says so:

Warning: pushing to <host> with GITHUB_TOKEN because neither GITEA_TOKEN nor FORGEJO_TOKEN is set. This fallback covers the push only: creating the release reads GITEA_TOKEN or FORGEJO_TOKEN, so it is skipped. The fallback goes away in the next major version: pass the token as GITEA_TOKEN (on Gitea or Forgejo Actions, `GITEA_TOKEN: ${{ secrets.GITHUB_TOKEN }}`).

doctor reports the token the push actually uses

token_env becomes token_check(forge, is_set), which returns the Check itself. It takes the "is this variable set" test as a closure so it can be tested without touching the environment.

• Unknown forge: GITHUB_TOKEN no longer turns the check green. It warns that the token is only sent to a remote recognised as GitHub, and points at workspace.forge or FERRFLOW_TOKEN. Before, doctor printed auth token: GITHUB_TOKEN is set right under its own "could not detect the forge" warning.
• Known forge: the variables come from ForgeKind::token_env_vars, the list the push and the API use. FORGEJO_TOKEN now counts for Gitea, where it was reported as missing.
• Gitea with only GITHUB_TOKEN: a warning that it covers the push until the next major, but releases need GITEA_TOKEN or FORGEJO_TOKEN.
• With --online: the forge is detected with the same probe the push uses, so a self-hosted forge the probe recognises is reported as that forge. Offline, the "could not detect" warning now mentions --online.

One forge resolver for push, API and doctor

Review found that doctor still resolved the forge differently from the push. The push (git::auth::forge_of) treated a host containing gitlab as GitLab before probing. doctor had no such shortcut, so on gitlab.corp.com, offline or with the probe blocked, it reported "forge unknown, only FERRFLOW_TOKEN is used" while the push authenticated with GITLAB_TOKEN. monorepo::preview::forge_target, the API side, also probed without the shortcut.

forge::resolve_forge(url, configured, Probe) is now the one resolver, used by all three:

1. an explicit workspace.forge
2. a host naming gitlab
3. the SaaS host list, then the probe when Probe::Allowed

The push and the API always allow the probe. doctor allows it only with --online, and never probes when forge is set explicitly (the probe used to run and be discarded). git::auth::forge_of and is_gitlab are gone.

One visible effect on the API side: a host containing gitlab is now taken as GitLab without probing, as the push already did since #1124.

Tests

Five new doctor tests on token_check:

• GITHUB_TOKEN alone on an unknown forge warns
• FERRFLOW_TOKEN is enough for any forge
• FORGEJO_TOKEN counts for Gitea
• Gitea with only GITHUB_TOKEN warns that releases need their own token
• a known forge without its token warns and names it

Three resolve_forge tests: a configured forge beats the host name, a host naming gitlab resolves without a probe, and an unknown host stays unresolved when probing is skipped while a SaaS host still resolves.

Full suite: 2513 passed.

Docs: the doctor section of reference/cli.md (EN, FR) describes the Forge check and --online accordingly.

[ferrfleet]

The Gitea push-only wording matches what github_token_fallback and build_forge_instance actually do, and token_check taking is_set as a closure makes the five new tests honest (no env mutation, no ENV_LOCK). token_env_vars is the right source for the variable list: FORGEJO_TOKEN counting for Gitea and the unknown-forge case no longer going green on GITHUB_TOKEN are both real fixes.

One blocking gap: the forge resolution here still differs from the one the push uses, so a self-hosted GitLab gets the wrong answer. Details inline, plus a nit on probing when the forge is configured explicitly.

[ferrfleet]

Both findings from the previous review are fixed in db2c6e0, threads replied to and resolved.

resolve_forge puts the push, the preview and doctor on one resolution order, and the three new tests pin it (explicit over host name, gitlab host without a probe, unknown host staying None when probing is skipped). Nothing new in the changed code.