[Bug]: Windows WSL backend does not receive Bitbucket credentials

Before submitting

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

Area

apps/desktop

Steps to reproduce

1. On Windows, configure either T3CODE_BITBUCKET_ACCESS_TOKEN or the T3CODE_BITBUCKET_EMAIL and T3CODE_BITBUCKET_API_TOKEN pair in the Windows environment.
2. Do not manually add those names to WSLENV.
3. Enable the managed WSL backend and fully restart T3 Code.
4. Open Settings → Source Control and rescan, or open the Pull requests page for a private Bitbucket repository.
5. Inspect the managed WSL server environment. The configured Bitbucket variables are absent.

The same symptom occurs when the variables are exported only from the WSL login profile: the WSL preflight captures the login-shell PATH, but the actual server is launched directly and does not retain arbitrary profile variables.

Expected behavior

The managed WSL server should receive the supported Bitbucket credential variables from the Windows desktop process, just as it receives the existing forwarded API-key variables. Bitbucket source-control operations should authenticate after restarting and rescanning.

Actual behavior

The desktop WSL launcher only adds OPENAI_API_KEY and ANTHROPIC_API_KEY to WSLENV. Bitbucket variables present in the Windows process are therefore dropped at the wsl.exe boundary.

Bitbucket requests run anonymously, private repository requests fail, and repeated source-control polling can exhaust Bitbucket's anonymous 60-request hourly quota. The Pull requests page then reports:

Could not load pull requests
Pull request operation list failed: bitbucket requests to bitbucket.org are paused until the rate limit resets.

Proposed fix: #7620

Impact

Major degradation or frequent failure

Version or commit

0.0.34-nightly.20260819.1133

Environment

Windows build 26200, T3 Code desktop with WSL-only backend, Ubuntu 24.04.4 LTS on WSL2, Node 24.18.0

Logs or stack traces

# Managed WSL server process environment (names checked; values not printed)
T3CODE_BITBUCKET_ACCESS_TOKEN=unset
T3CODE_BITBUCKET_EMAIL=unset
T3CODE_BITBUCKET_API_TOKEN=unset

# Bitbucket response metadata from the T3 server trace
http.response.status_code=429
x-credential-type=unauthenticated_identity
x-ratelimit-limit="60, 60;w=3600"
x-ratelimit-remaining=0
x-envoy-ratelimited=true

Screenshots, recordings, or supporting files

None.

Workaround

Define the credentials in the Windows environment, manually add their names to Windows WSLENV, then fully restart T3 Code. For example, preserve existing entries and append:

T3CODE_BITBUCKET_ACCESS_TOKEN/u

or:

T3CODE_BITBUCKET_EMAIL/u:T3CODE_BITBUCKET_API_TOKEN/u

Related: #5840 reports the same missing-credential symptom for macOS desktop shell profiles. It is not a duplicate because this report concerns the Windows-to-WSL launch boundary and WSLENV.

Start in apps/desktop by tracing the managed WSL launcher and how it constructs WSLENV before invoking wsl.exe. Verify the supported Bitbucket credential variables are forwarded without removing existing entries, then restart the managed WSL backend and confirm private Bitbucket source-control requests authenticate after rescanning.