docs: troubleshooting.mdx says the desktop app uses OPENCODE_PORT for its local server — nothing reads it #117

Problem

The English troubleshooting guide tells users debugging a desktop "Connection Failed" dialog to check OPENCODE_PORT:

• packages/web/src/content/docs/troubleshooting.mdx:132 — "If you have OPENCODE_PORT set in your environment, the desktop app will try to use that port for the local server."
• :134 — "Unset OPENCODE_PORT (or pick a free port) and restart."

Nothing in this repo reads OPENCODE_PORT. A user who follows this section will unset (or change) a variable that has no effect, while the actual port sources — the server.port config covered in the section directly above (:126-128), or the desktop sidecar's own choice — go unexamined for the case the guide attributes to the env var.

Evidence (verified this run, main 0bb248b075)

• git grep OPENCODE_PORT over the full tree returns hits only in the docs (the English page above and its translations). No reader in packages/desktop, packages/cli, packages/server, or anywhere else; no setter either.
• How the desktop's local server port is actually chosen in v2: packages/desktop/src/main/service/background-service.ts:51-57 — the sidecar is spawned with an explicit --port (a fixed 0x0c0c in the isolated case, with a comment explaining a fixed port makes a second contender fail to bind); the CLI/server path takes its port from the server config section, which is exactly what the troubleshooting section above this one tells users to remove.
• Dedup: this variable is not part of the cli.mdx env tables, so the audits in docs: OPENCODE_SERVER_USERNAME is promised but never read — basic-auth username is hardcoded to 'opencode' #103/docs: OPENCODE_ENABLE_EXA / OPENCODE_ENABLE_PARALLEL / OPENCODE_EXPERIMENTAL_BASH_DEFAULT_TIMEOUT_MS / OPENCODE_EXPERIMENTAL_LSP_TOOL are promised but read nowhere #105/docs: eleven more OPENCODE_* variables in the cli.mdx env table are read nowhere — DISABLE_PRUNE, DISABLE_AUTOCOMPACT, PERMISSION, TUI_CONFIG and seven others #114 (scoped to cli.mdx/tools.mdx) never covered it; issue searches for OPENCODE_PORT return no existing issue.

Why it matters

Troubleshooting docs are read by users who are already stuck. A step that cannot change anything burns the one restart cycle the user is willing to try, and misattributes the cause: a port clash from a stale OPENCODE_PORT is presented as a live possibility in v2 when the variable is v1 residue.

Acceptance criteria

Pick one direction and apply it consistently:

1. Align the docs with v2: remove the OPENCODE_PORT passage from troubleshooting.mdx (English source; translations follow the usual docs-locale-sync flow), keeping the working advice (the server.port/server.hostname config section above it). Or:
2. Implement it: make the desktop read OPENCODE_PORT when choosing its local server port, with a test showing the spawned server binds the requested port.

Filed-only: implement-vs-remove needs a maintainer decision (mirroring #103/#105), so no fix is attempted here. Single-repo: the guide and the desktop app live only in this repo.