[Bug]: gh credential lookups leak a dbus-daemon per call on hosts without a session bus (WSL)#23603

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. Run the T3 Code server on a host with no D-Bus session bus: WSL2, or headless Linux, where DBUS_SESSION_BUS_ADDRESS is unset and /run/user/<uid>/bus does not exist.
2. Sign gh in with its token stored in ~/.config/gh/hosts.yml, which is what gh auth login does when no keyring is available.
3. Open a project whose remote makes T3 ask gh for a token gh does not have in its config, for example an SSH alias remote git@github-hn:owner/repo.git (Host github-hn / HostName github.com in ~/.ssh/config), or pick a GitHub account in Settings → Source Control so T3 runs gh auth token --user <account>.
4. Leave T3 running and watch pgrep -cx dbus-daemon.

Expected behavior

T3's background gh calls leave no processes behind.

Actual behavior

Every gh auth token call that reaches gh's keyring starts a new dbus-daemon that never exits. gh reads the keyring through godbus (v5.2.2 in gh 2.97.0). With no session bus address, godbus autolaunches one with dbus-launch, and that daemon outlives gh. gh auth status --json hosts does the same for hosts with inactive accounts.

T3 repeats these calls whenever it refreshes git status or syncs pull requests. On my machine that added up to 162 orphaned dbus-daemon processes, re-parented to WSL's /init, in about five hours. Each one holds an inotify instance, and once fs.inotify.max_user_instances (128) ran out, unrelated programs crashed. OpenCode would not start: EMFILE: too many open files from fs.watch.

I traced the spawns with a logging dbus-launch shim on PATH. Every one came from gh auth token --hostname github-hn or --hostname github-ng, run by the T3 server process. The server trace shows these lookups under refineUnknownRemoteProvider, reached from ThreadPullRequestServiceV2.synchronize, ThreadSettlementServiceV2.sweep and RunFinalizationService.finalize.

Impact

Major degradation or frequent failure

Version or commit

T3 server 0.1.1 (WSL runtime); code path unchanged on main @ 8d3b0611

Environment

Windows 11 + WSL2 (Gentoo, kernel 6.18.33.2-microsoft-standard-WSL2), gh 2.97.0, desktop app running the server in WSL

Logs or stack traces

Workaround

Kill the orphaned daemons, then give gh a shared session bus: start one dbus-daemon --session and export its address, or put a dbus-launch shim on T3's PATH that returns an existing bus address instead of starting a new one.

A fix is proposed in #23549. The SSH-alias misclassification that triggered the calls here is tracked separately in #14919.