Show CLI-configured Forgejo/Gitea connections in Source Control settings

[Dunky13]

Users can already configure multiple Forgejo/Gitea servers through fj or tea, but T3 Code's Source Control settings show one account. Someone using two self-hosted servers under different usernames cannot inspect both connections in Settings.

Basic Forgejo/Gitea provider support is already shipped in #11436, as confirmed in #11932 and #6767. This proposal concerns visibility of those existing connections.

I submitted #17931 before obtaining approval for the expanded settings and discovery scope. It was closed pending scope approval and before/after evidence. I am requesting direction here before seeking reconsideration.

The proposed scope is:

• Expand the existing Forgejo/Gitea provider row to list CLI-configured server URLs, each connection's CLI, username, and authentication status. Use the existing design-system controls and masked account display.
• Read connections from both existing CLI configurations, deduplicating fj SSH aliases while preserving separate tea logins, ports, and URL mounts.
• Verify each configured fj account through the existing authenticated account-read path, sequentially with a five-second deadline per account. This adds authenticated read requests during discovery; total discovery time can increase with the number of configured servers. Retain unknown/offline connections and show bounded status/recovery diagnostics when verification fails.
• Keep configuration and credentials in fj/tea, and keep current repository/account routing. No new credential store, authentication flow, provider, or repository workflow.

The implementation is preserved on #17931 as a concrete reference. Focused discovery, routing, server registry, and settings-search tests passed (109 tests). The current commit fixes the reported account-diagnostic gap and has CodeRabbit correctness approval. CI did not execute because fork workflows await maintainer approval. Isolated desktop and mobile-web verification was completed; before/after screenshots are captured but have not yet been attached to GitHub. None of these results establishes scope approval.

Would maintainers accept this specific connection-inspection and account-verification scope? If discovery should avoid these additional account requests, I can revise the proposal to enumerate configured identities and verify them only on an explicit user action. I will request reconsideration of #17931 only after an approved direction and attached evidence.