[Bug]: Self-hosted Forgejo remote on a custom hostname logs GitHubNotSignedInError failure spans on every provider probe #29056

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. On a Linux server running t3 (seen on 0.1.7-nightly.20261101.4048), sign in gh to github.com only and sign in tea to a self-hosted Forgejo at https://git.example.com:3000 (a hostname without a forgejo or gitea label).
2. Open a project whose origin is https://git.example.com:3000/owner/repo.git.
3. Leave it running and read ~/.t3/userdata/logs/server.trace.ndjson.

Expected behavior

The Forgejo remote is identified through the tea login without recording failures. A "not signed in to GitHub for this host" answer from the GitHub probe is an expected, handled outcome, so it should not leave failure spans in the trace.

Actual behavior

forgejo's recognizeRemote only claims codeberg.org or hostnames with a forgejo/gitea label, so the remote is unknown and refineUnknownRemoteProvider runs every discovery spec. The GitHub spec's refineUnknownRemote calls GitHubRest.credential(host), which runs gh auth token --hostname git.example.com:3000; catchTags({ GitHubNotSignedInError: () => succeed(false) }) handles that correctly, but the inner spans have already been recorded as failures. Each re-probe (from PullRequestService.resolveRemoteHost and GitLabSourceControlProvider.refineRepositoryIdentity) writes five failure span groups:

• GitHubCredentials.get / GitHubCredentials.lookup: GitHubNotSignedInError: No GitHub credential for git.example.com:3000: run gh auth login --hostname git.example.com:3000.
• GitHubRest.credential: same message
• VcsProcess.run / VcsProcess.runUnbounded: VCS process failed in GitHubCredentials.get: gh (/home/deploy) exited with 1 - Authentication failed.

Stack excerpt:

GitHubNotSignedInError: No GitHub credential for git.example.com:3000: run `gh auth login --hostname git.example.com:3000`.
    at GitHubCredentials.lookup
    at GitHubCredentials.get
    at GitHubRest.credential
    at refineUnknownRemoteProvider
    at PullRequestService.resolveRemoteHost

On two servers this shows up as about 15 failure spans per hour, all for an outcome that is working as designed. Forgejo PR sync itself works.

Two possible fixes: run the GitHub credential probe for unknown hosts without failure-level spans (or in a span that treats GitHubNotSignedInError as success), and/or let a tea/fj login whose URL matches the remote claim the host in recognizeRemote, before every spec is probed.

Impact

Minor bug or occasional failure