[Bug]: Custom keybindings are ignored when Local environment is off and the app connects to the background service #15668

Before submitting

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

Area

apps/web

Steps to reproduce

1. Run the server as the background service (com.t3tools.t3code.service, t3 serve on localhost:3773, T3CODE_HOME=~/.t3).
2. In the desktop app, turn Local environment off (Settings → Connections) and connect to the service as a regular environment (http://localhost:3773/). It shows as Connected.
3. Swap two bindings in ~/.t3/userdata/keybindings.json (or via Settings → Keybindings):

   { "key": "mod+shift+n", "command": "chat.new",      "when": "!terminalFocus" },
   { "key": "mod+n",       "command": "chat.newLocal", "when": "!terminalFocus" }

4. Settings → Keybindings shows both rules with the Custom badge and the new keys.
5. Focus the composer in a thread and press Cmd+N.

Expected behavior

Cmd+N runs chat.newLocal and creates a thread in the current project, as configured on the connected environment.

Actual behavior

Cmd+N still runs chat.new and opens the "New thread in…" project picker. Custom keybindings are ignored by the keydown handlers. Reloading the window, re-saving the binding through Settings → Keybindings and restarting the desktop app do not change it.

Cause, from reading the shipped client bundle (0.0.46-nightly.20261004.2648):

• The keydown handler in the _chat route resolves commands from the web-primary-server-keybindings atom.
• That atom reads the config of the environment whose connection target is PrimaryConnectionTarget (web-primary-environment-id).
• With Local environment off there is no primary target, so the config is null and the atom returns mergeWithDefaultKeybindings([]) — the built-in defaults.
• Settings → Keybindings reads the connected environments in scope, so it shows the custom rules, while the handlers that act on key presses use the defaults.

Turning Local environment back on is not a workaround here: the desktop backend then starts a second server on the next free port with the same T3CODE_HOME as the service (see #6097).

Suggested fix: when there is no primary environment, resolve keybindings from the connected environment (or the one the active thread belongs to) instead of falling back to defaults.

Impact

Minor bug or occasional failure

Version or commit

Desktop 0.0.46-nightly.20261004.2648, server runtime 0.0.46-nightly.20261004.2648

Environment

macOS 27.0.1, desktop app with Local environment off, server running as the launchd background service

Logs or stack traces

No errors. The server log only shows the usual startup line:
WARN: default keybinding rule already defined in user config
  path: '/Users/<user>/.t3/userdata/keybindings.json'

Workaround

None, other than using the default bindings.