feat(api): GET /v1/projects — list the projects a caller can reach

[marcorivm]

Slice 1 of #20. 3 files, ~150 lines — the smallest useful piece, and independently valuable.

What and why

ossProjectRoutes defines only /:projectId and /:projectId/access — there is no way to enumerate projects. Upstream serves the collection from its closed cloud backend, so the OSS build 404s it. That gap is why groups (#12) and project access (#13) feel inert: the thing they grant access to can't be discovered.

This adds GET /v1/projects and listProjects.

The one thing worth reviewing carefully

listProjects must mirror canAccessProjectAsUser arm for arm — it is that per-row predicate expressed as a query. Drift either way is a real bug: listed-but-unreadable leaks a project name past its ProjectAccess bindings; readable-but-unlisted is a project you can reach but never find.

	canAccessProjectAsUser	listProjects
!CAPS.rbac	return true	whole org
no role (suspended / non-member)	return false	[]
admin or owner	return true	whole org
otherwise	hasProjectBinding	projects with a binding, direct or via group

role is deliberately not filtered in the binding arm — usage is role-blind, so a plain member binding is a full use grant. A test asserts the two agree for every seeded project:

it("agrees with GET /:projectId — everything listed is readable, and vice versa")

The route carries no authorization of its own, on purpose. Unlike every other route in the file there is no id to resolve, so there is nothing to 404 and nothing to 403. listProjects is the authorization. A member of the org holding no bindings correctly gets [], not a 403 — asserted explicitly.

Upstream

Matches upstream's client contract (Project[], optional X-Organization-Id override), so this also closes the v1.45.0 GetStartedPicker 404 recorded in docs/upstream-sync/reviews/2026-08-05-v1.45.0.md.

Ordering is createdAt asc, id asc — the same as findUserDefaultProject, so the project you land on by default is the first one a switcher will show.

Tests

12 new cases in projects.test.ts (76 passing in the file, 1,156 across @onecli/api). Cross-org isolation, the group-binding arm via MEMBER2, the zero-binding project (proj-4) staying invisible to a plain member, response shape leaking neither createdByUserId nor organizationId, and 401/403 on the guard stack.

One finding while writing them. I expected a suspended member to get 200 []; they get 401. Session auth resolves the default project through activeMembershipWhere, which a suspended member fails, so neither project nor org resolves and the request is rejected a layer earlier. listProjects's own if (!role) return [] arm is therefore defence-in-depth for direct service callers rather than a path this route can reach — kept anyway so the function mirrors the gate without depending on its caller having gated first. Both tests now assert the real behaviour, with the reasoning in a comment.

Verification

pnpm --filter @onecli/api test    # 1156 passed, 0 failed
pnpm run check                    # lint + types + format clean