fix(app): show server-known projects in project lists

[weiconghe]

Issue for this PR

Closes #43072

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

The project list in the home panel and the session sidebar is fed exclusively by a locally persisted store (Persist.global("server"), i.e. opencode.global.dat), and the only thing that ever writes to it is createServerProjects.open() when a project is opened through the UI. The server-side project list (/project, fetched once at startup by loadProjectsQuery in packages/app/src/context/global-sync/bootstrap.ts) goes into globalStore.project and is never merged into either list. So a project the agent creates during a chat — or any directory the CLI has registered — never shows up in the app, even after a restart; the only workaround is adding the folder manually through the project picker.

This makes it look like the agent failed to create the project (that is exactly how the issue reporter experienced it), and it makes every CLI-known project invisible in the desktop/web app.

The fix appends server-known projects that were never opened after the user-opened ones, newest first, capped at 10 so a long CLI history can't flood the list:

• knownProjectWorktrees() in packages/app/src/context/server.tsx — pure helper: filters out global and empty worktrees, dedupes against opened projects via pathKey (so D:\x and D:/x match), sorts by time.updated descending, caps at 10.
• projectsList in packages/app/src/context/global.tsx (home panel) and enriched in packages/app/src/context/layout.tsx (sidebar / page logic) now union the appended entries through the existing enrich(), so icons and metadata resolve the same way as for opened projects. The union is render-only — the persisted store still contains only user-opened projects.

Two existing behaviors are intentionally kept on the raw store so the appended entries can't change their semantics:

• autoselect (packages/app/src/pages/layout.tsx) reads server.projects.list() instead of the unioned list, otherwise a fresh install with server-known projects would auto-open one of them instead of restoring the last opened project.
• "add project" in the home controller compares against a new ctx.projects.opened (pre-union list), so explicitly adding a directory that is already server-known still persists it to the store.

This follows the same direction as #41018, which made opening a project from home register it; this covers the projects nobody has opened yet.

How did you verify your code works?

• bun run test:unit in packages/app: 729 pass / 0 fail, including 5 new tests for knownProjectWorktrees (union order, cross-separator dedupe, cap, global/empty filtering, empty inputs).
• Manually on Windows 11 with opencode serve (1.18.21, 13 projects registered in the local DB) plus bun dev in packages/app and a fresh browser profile:
  • before: the project panel is empty ("Add project" only) while GET /project returns 13 projects;
  • after: the panel lists 10 server-known projects (cap working: 12 candidates), each with icon and metadata resolved via enrich().
• tsgo -b typecheck cannot run on my Windows checkout for pre-existing reasons: packages/app/src/custom-elements.d.ts is a symlink in the repo, and the Windows checkout materialized it as a 33-byte text file, so a clean dev checkout already fails with TS1128 before any of my changes. CI will run the typecheck on Linux. I did not run the browser e2e suite locally.

Screenshots / recordings

Before (13 server-known projects, panel empty):

After (same server, fresh profile, panel lists the capped known projects):

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[weiconghe]

The check-duplicates failure looks like infrastructure flake rather than an actual duplicate finding — the job log shows the script timing out on its first API call with zero analysis output (TimeoutError right after env setup), and it only runs on opened, so a re-push doesn't retrigger it.

For what it's worth, I did search before opening: no open PR references #43072, and a keyword search over open PRs (project list sidebar, issue number) returns nothing but this PR.