desktop: @-mention file links keep the literal "@" in the path and fail (404/500) #53502

Summary

In the OpenCode desktop app, clicking an @-mention link to a file in chat fails to open it. The client sends the mention text including the leading @ to the file-read API, so it requests a path literally named @… and gets a 404. Clicking a mention that points to a directory instead hits the file-reader and returns 500.

Environment

• opencode version: 2.0.24 (desktop app bundle is also 2.0.24)
• OS: Darwin 27.0.0 (darwin arm64)
• Terminal: N/A — OpenCode desktop app (Electron), not the TUI
• Shell: /bin/zsh
• Install/channel: latest
• Active plugins: none in project config; global ~/.config/opencode/plugins contains a user plugin (honcho.ts). No project .opencode/plugins.

Reproduction

1. In the desktop app, open a session whose workspace contains a file, e.g. TRUTH_max-seed/README.md (a brand-new, untracked file).
2. In chat, click an @-mention link pointing at that file (@TRUTH_max-seed/README.md).
3. The app shows Failed to load file — UnexpectedStatus: 500 (or 404).

Expected Behavior

Clicking a mention opens the referenced file (or navigates into the folder for a directory mention).

Actual Behavior

The client strips nothing and requests the mention verbatim, so the @ ends up in the path.

Server log (workspace-scoped request from the desktop client):

http.method=GET http.url=/api/fs/read/%40TRUTH_max-seed/README.md http.status=404

%40 is a literal @. The client is asking the server to read a file named @TRUTH_max-seed/README.md.

Directory mention (@TRUTH_max-seed) instead routes to the file-reader and 500s:

cause="Error: Path is not a file
    at FileSystem.read (/$bunfs/root/chunk-fd05ppfs.js:444:16637)
    at ServerProcess.start (.../chunk-1v3746hj.js:2:6612)"
http.method=GET http.url=/api/fs/read/TRUTH_max-seed http.status=500

The server and path are fine — the same file reads correctly when called directly, scoped to the location:

GET /api/fs/read/TRUTH_max-seed/README.md
    ?location[directory]=/Users/<user>/Desktop/<workspace>
→ HTTP 200 (returns file contents)

Additional Context

• The two symptoms share one root cause in the client: the mention target is not normalised before being sent to fs/read — the leading @ is not removed, and directories are not handled (a directory should navigate, not read).
• Not fixable via config or plugin: the link handler lives in the desktop client (app.asar); plugins/hooks are server-side.
• Reproducible consistently.
• Related but separate: the sidebar file tree and git panel stayed stale after new (untracked) files appeared, until POST /api/location/reload forced a rebuild. Files were never missing on disk and the server API reported them correctly. May be a distinct client-caching issue worth a separate report.