feat(web): project switcher and create dialog

[marcorivm]

Slice 3b of #20, stacked on #23. 5 files, ~230 lines. The UI on top of 3a's transport.

A dropdown in the sidebar lists the projects you can reach, marks the active one, switches between them, and opens a dialog to create one. This is the slice that makes the whole stack visible: create → list → switch now works end to end.

Two details that are easy to get wrong

Switching clears the entire query cache, not just the project list.

queryClient.clear();
router.refresh();

Query keys are scoped by getProjectId() — an undefined stub in this edition (api-fetch.ts:5). So changing project does not change any query key, and cached agents, secrets and policy would keep being served for the previous project. Invalidating just projects.list() would look right and be silently wrong. router.refresh() follows because the cookie only reaches the server on the next request and most of the dashboard is server-rendered.

useCurrentProjectId mirrors the server's resolution chain rather than guessing it. Cookie wins when set; the session's default answers when it isn't. That ordering isn't arbitrary — the session endpoint resolves through findUserDefaultProject and ignores X-Project-Id, so it always reports the default project, never the selected one. If the cookie didn't take precedence the switcher would show the wrong project the moment you switched.

The cookie is read in an effect rather than during render, since it lives on document — reading it while rendering would mismatch the server-rendered HTML. undefined on first paint is correct and momentary.

Smaller choices

• The list is already filtered server-side, so there's nothing to gate client-side. An empty list renders nothing rather than an empty control.
• Creating switches to the new project — safe because the API seeds the creator as owner in the same write (feat(api): POST /v1/projects — create a project, owned by its creator #22), so it's immediately usable and manageable.
• No duplicate-name check in the dialog: projectNameSchema deliberately permits duplicate names and the API disambiguates slugs silently. Validating against it would contradict the API.

Tests

None — same deliberate gap as #23. apps/web has no vitest harness on the 1.44.0 base; upstream ships apps/web/vitest.config.ts in v1.45.0, and adding one here would collide with that adoption.

Verified instead with:

pnpm run check                    # lint + types + clippy + format, 9/9 tasks
pnpm --filter @onecli/web build   # builds clean

Once the v1.45.0 harness lands, useCurrentProjectId's precedence and the cookie helpers are the first things worth covering.