Desktop app: file links only open when the path is inside the session's primary working directory

## Problem

In the desktop app's Code tab a session routinely spans more than one folder: a notes vault plus a
code repository, a primary checkout plus a git worktree, or a repository added through the
directory-access tool. Any file link written for a file outside the session's primary working
directory renders as a link but does nothing when clicked, and looks identical to one that works.
Every such link costs a click to discover it is dead.

## Current behavior

Measured on macOS (Darwin 25.6.0), desktop app 1.44121.4, Claude Code 2.1.258. Session working
directory `~/vault`, with `~/.claude`, `/tmp` and `~/Downloads` additionally granted to the session.

| link target | form | result |
|---|---|---|
| `AGENTS.md` — inside working dir | relative | opens |
| `~/vault/AGENTS.md` — inside working dir | absolute | opens |
| `~/code/project-b/docs/file.md` — other repo | absolute | dead |
| `../code/project-b/docs/file.md` — other repo | relative | dead |
| `~/.claude/keybindings.json` — granted folder | absolute | dead |
| `/tmp/link-test.md` — granted folder | absolute | dead |
| `cursor://file/Users/me/code/project-b/docs/file.md` | editor scheme | dead |
| `obsidian://open?vault=vault&file=AGENTS.md` | app scheme | dead |
| `file:///Users/me/code/project-b/docs/file.md` | file URL | dead |

Granting a folder to the session gives read and write access but does not make links into it
openable. Access and clickability are separate, and the second one cannot be granted. Custom URL
schemes are not a workaround either, so there is currently no way to hand the user an openable
reference to a file outside the working directory.

## Desired behavior

1. A file link resolves and opens for any folder the session has been granted, not only the
primary working directory.
2. Where the app will not open a file itself, offer to open it in the user's editor. The app
already ships an editor launcher (VS Code, Cursor, Zed, Windsurf, Xcode, detected by URL
scheme) — expose it as a preference, e.g. "open files outside the workspace in ".
3. A link that cannot be opened should be visibly non-clickable rather than silently inert.

## Acceptance criteria

- Clicking a link to a file in any granted folder opens it.
- A setting selects the external editor, and it is used for files the built-in viewer will not open.
- No rendered file link is silently inert.

## Workaround

Root the session in the repository being discussed and hand every other path to the user as plain
text to copy. This limits one session to one repository with working links.

Start by tracing file-link handling in the desktop app's Code tab and the existing editor launcher for VS Code, Cursor, Zed, Windsurf, and Xcode. Compare behavior for primary-workspace and granted-folder paths, then verify the acceptance criteria: granted files open, an external-editor setting is honored when needed, and unsupported links are visibly non-clickable.

Written by the indexing model from the issue text.