[Bug]: Packaged Windows build fails Gitea authentication while dev build connects with the same environment variables

### Operating system

Windows

### Orca version

1.4.183

### Details

**Summary**

On the packaged Orca build for Windows (1.4.183), the Gitea integration card (Settings -> Integrations) reports "Gitea credentials are configured but could not authenticate..." even though `ORCA_GITEA_TOKEN` and `ORCA_GITEA_API_BASE_URL` are set as user/system environment variables. The dev build launched from the exact same v1.4.183 source shows the card as Connected with the same variables.

**Environment**

* OS: Windows 11 Pro x64 (packaged desktop app)
* Orca version: 1.4.183 (installed, launched from the desktop/Start-menu shortcut; dev build from the same v1.4.183 branch via `pnpm dev`)
* Gitea server: HTTPS with a valid certificate (no self-signed certificate involved)
* No Active Server / remote runtime configured; the Gitea status check runs in the local main process
* Native Windows checkout; WSL is not involved in this check

**Reproduction steps**

1. Set `ORCA_GITEA_TOKEN` and `ORCA_GITEA_API_BASE_URL` as user/system environment variables (e.g. `setx` or System Properties).
2. Launch the installed Orca from the desktop/Start-menu shortcut.
3. Open Settings -> Integrations -> Gitea: the card shows "Gitea credentials are configured but could not authenticate. Check the token, API base URL, and repository permissions, then restart Orca if environment variables changed."
4. Open a new terminal (started after the env vars were set) and launch the dev build from the same v1.4.183 source: the same card shows Connected.

**Expected**

The packaged build authenticates with the same environment variables the dev build uses.

**Actual**

The packaged build reports `not-authenticated`: the `GET /api/v1/user` request fails. The token is visible to the process (otherwise the card would show the unconfigured state), so the request is made with a stale or mismatched credential value. The dev build succeeds.

**Analysis**

* `getGiteaAuthStatus()` (`src/main/gitea/client.ts`) reads `process.env.ORCA_GITEA_TOKEN` / `ORCA_GITEA_API_BASE_URL` in the Electron main process; the card status flows through the `preflight:check` IPC handler (`src/main/ipc/preflight.ts`). Token-based providers (Gitea, Bitbucket, Azure DevOps) are always checked in the local main process even when a WSL project runtime is configured.
* No disk-persisted cache exists for the Gitea status (only GitHub has `orca-github-cache.json`); the preflight result is cached in memory for the session and the process environment is frozen at launch.
* Windows copies the parent process environment at process creation. Explorer does not refresh its snapshot when environment variables change, so an app launched from a shortcut keeps the old values (e.g. a rotated token or an outdated API base URL) until Explorer is restarted or the user signs out/in. A dev build launched from a terminal opened after the change inherits the current values - this matches the observed dev-works / packaged-fails split.
* The card hint "restart Orca if environment variables changed" only helps when the launching parent already holds the new values.

**Frequency**

Consistent. Every launch via shortcut reproduces it; pressing Re-check does not change the result because the process environment is fixed at launch.

**Related**

* Feature request "[Feature]: Surface the actual Gitea API error when integration auth fails" (stablyai/orca#13786) - surfacing the real API error would make this class of issue diagnosable from the UI.

**Media**

* Screenshot 1: Gitea integration card in the packaged build showing the authentication failure.

* Screenshot 2: Gitea integration card in the dev build showing Connected.

Start with src/main/gitea/client.ts and the preflight:check handler in src/main/ipc/preflight.ts, then compare the environment inherited by the packaged shortcut with the pnpm dev launch. Trace how the packaged Windows process obtains ORCA_GITEA_TOKEN and ORCA_GITEA_API_BASE_URL; done means the installed build authenticates consistently when the same variables are configured.

Written by the indexing model from the issue text.