feat(relay): BUZZ_WEB_SPA=full to serve a full client bundle

[flaukowski]

Problem

should_serve_spa only falls back to the SPA shell for the invite landing page, and optionally the bundled git browser:

fn should_serve_spa(path: &str, serve_git_web_gui: bool) -> bool {
    is_invite_landing_path(path) || (serve_git_web_gui && is_git_web_gui_path(path))
}

A deployment that points BUZZ_WEB_DIR at a full client bundle has no way to get client-side routing for its own paths — every route needs a bespoke predicate compiled into the router. Any client-side route reached by deep link or refresh 404s.

Change

Add BUZZ_WEB_SPA=full. When set, any path the relay does not serve itself falls back to index.html.

Server-owned paths still return their own responses, so a mistyped API call 404s instead of returning HTML that a client would then try to parse as JSON:

/api/…, /git/…, /hooks/…, /media/…, /upload, /.well-known/…, /_*, /events, /query, /count, /info, /health, /moderation

Defaults to false. With the variable unset, behaviour is unchanged.

Tests

Three new cases in crates/buzz-relay/src/router.rs:

• full_spa_mode_serves_arbitrary_client_routes — opt-in serves paths the relay has never heard of
• full_spa_mode_still_lets_server_paths_404 — every server-owned prefix must not fall back
• full_spa_mode_is_off_by_default — unknown paths still 404 without the opt-in

Plus a default-value assertion in the config tests, and a TESTING.md row for the new variable.

Context

We run a self-hosted Buzz deployment whose web bundle is a full workspace client. We had been carrying a hardcoded path predicate in should_serve_spa to make it work; this generalises that into an opt-in flag so the fix isn't per-route, and lets us drop the local patch.

🤖 Generated with Claude Code