[BUG] Windows: session.path for non-git projects is drive-dependent, hiding sessions from /sessions based on launch drive

Description

On Windows, session.path for sessions in non-git projects (the global project) is computed relative to path.resolve("/"), which anchors to the drive root of the process working directory. The same physical directory therefore gets different relative paths depending on which drive opencode was launched from:

// packages/opencode/src/session/session.ts
function sessionPath(worktree: string, cwd: string) {
  return path.relative(path.resolve(worktree), cwd).replaceAll("\\", "/")
}

Non-git projects set worktree to a synthetic "/" (project.ts:217), so:

• opened from C:\Users\foo → stored path is Users/foo/...
• opened from D:\Dev\... → the same directory produces Dev/... or, cross-drive, an absolute-style C:/Users/foo/... result

The TUI's directory filter (packages/tui/src/context/sync.tsx sessionListQuery()) uses the same computation at query time, so sessions created from one drive disappear from /sessions when opencode is launched from another drive. In practice: sessions created in the home directory vanish from the session picker every time opencode is started from a folder on another drive.

Observed on 1.18.16 with a DB containing 121 sessions stored as path='Users/wxj20', 48 with path=NULL, and a few Dev/... sessions: from C:\Users\wxj20 the picker shows the 121, from D:\Dev\... it shows only the Dev/... ones.

Plugins

None

OpenCode version

1.18.16

Steps to reproduce

1. On Windows, launch opencode in a non-git directory on drive C: (e.g. C:\Users\foo) and create a session.
2. Verify the session is stored with path like Users/foo.
3. Launch opencode in any non-git directory on drive D: (no --directory), open /sessions.
4. The session created in step 1 is not listed, even though it belongs to the same project.

Screenshot and/or share link

N/A

Operating System

Windows 11

Terminal

Windows Terminal / PowerShell

Notes

• The writer and query side both use path.resolve("/"), which is launch-drive dependent on win32; anchoring "/" to the directory's own drive root makes stored paths deterministic. A fix is prepared in # (see also #38532 for scoping the default list by exact directory).