Forgejo / Gitea: use tea's environment login (GITEA_INSTANCE_URL / GITEA_TOKEN)

[alcxyz]

tea can log in from the environment instead of a stored login: GITEA_INSTANCE_URL and GITEA_TOKEN (plus optional GITEA_INSTANCE_SSH_HOST). This is the usual choice when the token should not sit in plaintext in tea's config.yml, for example in containers, CI-like environments, dev shells, or when the token comes from a secrets manager (sops, agenix, 1Password, systemd credentials) through a small wrapper.

T3 Code's Forgejo / Gitea provider only sees stored logins, so with an environment login:

• Settings shows Not authenticated ("Run tea login add...").
• Pull request features fail with "No matching Forgejo login", although every tea command T3 needs works.

Related but distinct: #18122 is about listing several stored connections; this is about the case where there is no stored login at all.

Reproduction (tea 0.16.0, current nightly)

With an empty tea config directory and only the two environment variables set:

tea login list --output json    -> []
tea login status --output json  -> []
tea api /user                   -> 200, returns the user
tea pulls ls --repo owner/repo  -> works

In packages/source-control-forgejo/src/server/, discovery's parseAuth reads tea login status and the CLI layer selects a login from tea login list via matchForgejoLogin, so both report nothing to use.

Today the workaround is to keep a token-less stored login for the instance (so T3 can match it) and have a tea wrapper drop T3's --login <name> so tea falls back to the environment login. It works, but it depends on T3 internals, and Settings still shows Not authenticated.

Proposed scope

• When no stored tea login matches the repository remote, and GITEA_INSTANCE_URL in T3's environment matches the remote's host (or GITEA_INSTANCE_SSH_HOST matches an SSH remote), run tea without --login, so tea's own environment login applies. Only the URL needs to be visible to T3; the token can be set by tea's caller or a wrapper.
• For that case, determine auth status by asking the server (tea api /user) instead of tea login status, and show it as authenticated with the returned username.
• No change when a stored login matches; stored logins keep precedence. No new credential store or settings, and T3 never reads the token itself.

Would maintainers accept this scope? If the auth probe should avoid an extra request during discovery, it could instead report the environment login as configured without verifying it.