Re-apply tenant lookup refactor with routing fix

[rchlfryn]

Description

Re-applies the tenant lookup refactor from #897 (which was reverted in #926). This replaces the dynamic Edge Config / API-based tenant resolution with a hardcoded AVALANCHE_CENTERS list as the single source of truth for valid tenant slugs, making middleware synchronous and deterministic.

Also fixes a routing issue where pages were falling through to [...segmentsNotFound] in preview.

Why dynamicParams = true?

The routing works in two phases with different capabilities:

1. Middleware (edge, no DB access) — decides "is this a valid center slug?" and rewrites the URL
2. Layout (server, has DB access) — decides "can I actually render this center?"

With dynamicParams = false, there's a rigid third gatekeeper between them: the build-time generateStaticParams() output. That list must perfectly match what middleware sends — if it doesn't, for any reason, routes silently fall through to the catch-all instead of rendering the appropriate not-found page.

With dynamicParams = true, that rigid middle layer is removed. Middleware handles "is this slug valid?" and the layout handles "does this center have data?" Each layer does what it's best positioned to do with the information it has access to. generateStaticParams() still pre-renders centers in the DB — that's a performance optimization, not an access control mechanism.

Why notFound() instead of invariant?

invariant throws a regular error → 500-style error page. notFound() throws a Next.js-specific error → proper 404 page. With dynamicParams = true, reaching the layout with a center that has no DB data is now an expected path (not a bug), so a 404 is the correct response.

Reverts #926

Related Issues

#897

Key Changes

Newly added to fix false 404s

• dynamicParams = true: Centers in the DB are pre-rendered at build time; others are served on-demand with graceful 404 handling d370ef0
• invariant → notFound(): Proper 404 pages instead of 500-style crashes when a center lacks DB data c34ee93

How to test

1. Visit a center that exists in the DB (e.g., nwac.localhost) — should render normally
2. Visit a center in AVALANCHE_CENTERS but not in the DB — should show the not-found page, not crash
3. Visit a completely invalid slug — should show the not-found page
4. Verify the admin tenant selector still works correctly
5. Test custom domain routing in a preview deployment

[github-actions]

Preview deployment: https://fryanxrevert-926-revert-1x7x0.preview.avy-fx.org

[busbyk]

Couple error/404 scenarios here:

• valid tenant slug but tenant does not exist in payload
  • should: 404 and show non-center scoped 404
  • this branch/PR: notFound thrown in layout.tsx RSC but we don't have a custom not-found page one level up so next.js 404 page shown (black page with white 404 text)
• invalid tenant slug
  • should: 404 and show non-center scoped 404
  • this branch/PR: shows src/app/(frontend)/page.tsx -- I wonder if this is because of the dynamicParams change. But it might just be related to the middleware. I didn't get a chance to test on the target branch/PR.

Custom domain routing for both src/app/(frontend)/[center]/[slug]/page.tsx and src/app/(frontend)/[center]/[...segments]/page.tsx seem to work in this PR so that's good.

[busbyk]

Was this throwing an error without these empty object returns?

[rchlfryn]

Not in practice but it could happen in theory - these are added now that dynamicParams = true

With dynamicParams = false, Next.js 404s before reaching the route for slugs not in generateStaticParams, so generateMetadata was never called for invalid slugs.

With dynamicParams = true, generateMetadata can be called for any slug — including ones without settings/tenant in the DB. The layout's notFound() should prevent this, but Next.js may call generateMetadata in parallel with the layout, so these guards prevent a crash if notFound() hasn't fired yet.

[busbyk]

Yea good call that the RSC and generateMetadata are called in parallel. Would it make more sense to return some basic error state metadata instead of an empty object like:

{
  title: 'Not found',
  description: '...' // not sure what the description would be - we could omit this
}

It sounds like since the not-found page is nested within this layout, this metadata will be used if that's rendered.

[rchlfryn]

Good point! I'll update the fallback to return { title: 'Not found' } — since it's more useful metadata than an empty object, especially since the not-found page will inherit it. I'll leave out description since there's nothing meaningful to say there.

[rchlfryn]

Two 404 issues you noted:

Valid tenant slug but no DB data → shows Next.js default 404 (black page) instead of a custom not-found page

When notFound() is called from the [center] layout, Next.js looks for a not-found.tsx above that layout. The existing [center]/not-found.tsx is a child of the layout, so it can't catch errors thrown from it. There's no (frontend)/not-found.tsx, so Next.js falls back to its default black page.

Fix: Add src/app/(frontend)/not-found.tsx with a styled 404.

Invalid tenant slug → shows src/app/(frontend)/page.tsx (the landing page) instead of a 404

I think this is a middleware gap. When an unknown subdomain like invalid.localhost:3000/ comes in, middleware loops through TENANTS, finds no match, and falls through to passthrough. The request hits Next.js with path /, which matches (frontend)/page.tsx — the landing page. isValidTenantSlug in the layout can't help because middleware never added a slug prefix, so the layout never sees the invalid slug at all.

Fix: Return a 404 from middleware when a subdomain doesn't match any known tenant.

[busbyk]

@rchlfryn I pushed a few changes. Tried to be descriptive enough in my commit messages but let me know if any of those need further explanation.

I'm happy to merge this into #947 if you think my commits look good.

I'm interested in removing custom domain from the db and just depending on the custom domain configured in src/utilities/tenancy/avalancheCenters.ts so I'd like to open that as a PR off of #947 after this PR merges. Then we can test custom domains in preview and call it good.

[rchlfryn]

@busbyk I think changes look good! I will go ahead and squash and merge this into the revert and you can make a PR off of that.