fix: let a user removed from their last organization recover

[FrameAutomata]

Closes #292.

Stacked on #312. Base is fix/setup-test-duckdb-build-constraint, so the diff here shows only this change and the DuckDB CI job stays meaningful — without #312 that job fails on the unrelated #309 build-constraint bug. GitHub retargets this to main automatically when #312 merges.

The stuck state

+layout.svelte:159 pins every zero-project account to /setup:

const needsSetup = $derived(authState.isAuthenticated && projectsState.projects.length === 0);

and /setup's only branch for a user with no writable org was a sentence with no action:

You need an owner, admin, or user role in an organization to create projects.

Remove someone from their last organization mid-session and their project list empties, the layout locks them to /setup, and /setup offers no way out. Every other route bounces back.

Three parts

1. POST /api/organizations. OrganizationRepository.Create had exactly two call sites — auth.controller.go:149 (register) and oauth.controller.go:270 (SSO finish-setup) — both account-creation paths. An existing user had no way to create an organization, so the issue's "asking them if they want to create one" needed a new endpoint. The caller becomes owner.

• Timezone defaults to UTC and is validated with time.LoadLocation. On-call schedule resolution is tz-aware calendar math, so an unparseable zone would surface much later as wrong shift boundaries rather than as an error here.
• Cloud gating follows the existing hook pattern (ProjectLimitHook, MemberLimitHook, CheckLimitHook). OrganizationLimitHook is keyed on the user, not an org, since it runs before the org exists — commented at the declaration because it breaks the shape of its siblings.
• Name validation is length-only (1–100 runes), deliberately not projectNameRegex: that regex rejects , and ., which real company names contain.

2. /setup splits the two cases it used to collapse. Zero organizations gets a create form; organizations that are all readonly keeps today's message, which is correct advice in that case.

3. Stale membership. authState.organizations is hydrated from localStorage (auth.svelte.ts:12) and only rewritten on login, so a mid-session removal stays cached — meaning the recovery screen would otherwise render a selector for an org the user is no longer in and offer a project flow that 403s. /setup now refreshes from /me/login-bundle on mount and shows a loading state until it resolves.

Also included

backend/app/controllers/routes_test.go — registers the real route tree. Gin panics at registration on a wildcard conflict, which is a boot-time crash no handler test would catch, and POST /api/organizations is a static sibling of the /api/organizations/:organizationId/... subtree — the shape most likely to trip it. Nothing else in the suite covered route registration. Untagged, so it runs in all three CI jobs.

Verification

Check	Result
go test ./... (default)	exit 0
CGO_ENABLED=1 go test -tags telemetry_duckdb ./app/controllers/	ok
go vet ./... / gofmt -l .	clean
New endpoint tests (4 tests, 7 cases)	pass
routes_test.go under all three build-tag combos	pass
npm run check	0 errors; 12 pre-existing warnings, none in the changed file

Not verified

I did not run the app and click through the flow — the recovery path is covered by unit tests at the handler level and by svelte-check at the type level, but the rendered /setup screen itself is untested. Worth a manual pass before merge: remove yourself from your last org in a second browser session and confirm the create form appears and lands you in a working project setup.

🤖 Generated with Claude Code