Desktop: project picker sends host paths to a remote server, and the resulting failure is silent

Environment

• opencode desktop app 1.18.21, macOS
• opencode serve 1.18.21 running inside a Linux dev container, attached over HTTP
• Repository is bind-mounted into the container at /workspaces/<repo>

What happens

Attach the desktop app to the remote server, pick the project, send a message.
Nothing comes back. No error, no spinner that ends, no failed state — the
message simply sits there. I sent three before going to look at the server.

The server log explains it:

level=ERROR message=failed
  error="PlatformError: NotFound: FileSystem.realPath (/Users/<user>/Projects/<repo>)
         (cause: Error: ENOENT: no such file or directory,
          lstat '/Users/<user>/Projects/<repo>')"

level=ERROR message="prompt_async failed" sessionID=ses_...
  cause="Cause([Die(PlatformError: NotFound: FileSystem.realPath (/Users/<user>/Projects/<repo>))])"

level=WARN message="failed to initialize fff"
  error="Failed to init file picker: Invalid path /Users/<user>/Projects/<repo>"

and the session was created with the host's path:

message=created id=ses_... directory=/Users/<user>/Projects/<repo> ...

/Users/<user>/Projects/<repo> is the path on my Mac. The server is in a Linux
container where the checkout lives at /workspaces/<repo>, so that string means
nothing there.

Two separate problems

1. The project picker browses the local filesystem while attached to a remote
server. This looks like the root cause rather than a marshalling slip: when the
app is attached to a remote server, the picker still shows my Mac's directories,
so whatever I choose can only ever be a host path. #40136 ("don't forward host
directory to remote workspace") and #5380 (attach --dir referencing the local
directory) fixed this class of problem on other paths; the desktop-app-to-remote-
server path still has it.

Should the picker browse the server's filesystem when attached remotely? If
there is already a supported way to open a project by its server-side path, I did
not find it.

2. The failure is completely silent in the UI. This is arguably the worse
half. prompt_async failed is a server-side error with a clear cause, and none
of it reaches the client — the app looks idle rather than broken. Surfacing it
would have turned a long debugging session into a five-second fix, regardless of
what happens with the path handling.

Workaround, in case it helps others

Mount the checkout a second time inside the container at the same absolute path
it has on the host, so both names refer to the same directory:

-v /Users/<user>/Projects/<repo>:/Users/<user>/Projects/<repo>

A symlink also lets the files be read, but realPath resolves it back to the
container path and the server then reports that back to the client, so the
mismatch just reappears on the return trip. A second bind mount has nothing to
resolve: realPath returns the same string the app sent, which is valid on both
sides.