Answer 404 for a path this server does not serve

[ppXD]

Summary

Opening an invite link returned 401, which read as "you need to sign in" — for a person who has no account yet, that is exactly the wrong thing to say, and it sent the investigation after an authorization bug that did not exist. InvitationsController is [AllowAnonymous] and works:

/api/invitations/{token}  → 404 {"code":"invitation_not_usable", …}   ← endpoint fine
/invite/probe             → 401 (empty)                                ← no such route
/nonexistent-route        → 401 (empty)                                ← no such route

The cause is the global FallbackPolicy: it requires an authenticated user for endpoints without an explicit [Authorize] — deliberately — and it also applies when nothing matched. There the 401 is a lie; the request was refused for want of a route.

The immediate trigger was App:PublicBaseUrl naming the API host instead of the SPA, so InviteUrl minted https://<api-host>/invite/{token}. The boot banner now prints where links will point, so that is visible before anyone sends one.

Why a fallback endpoint, not middleware

The first attempt was middleware before UseAuthorization keyed on GetEndpoint() == null. An adversarial review (17 agents, 13 candidate findings, 7 confirmed) caught two regressions in it, both verified by live A/B against this exact pipeline:

• Hangfire's dashboard would have been unmounted. UseHangfireDashboard is app.Map branch middleware and registers no endpoint, so GetEndpoint() is null for /hangfire and the middleware swallowed it — making UseCodeSpaceHangfire dead code on the API role, with no test able to see it (the E2E factory runs the Worker role, which mounts no dashboard).
• The boot banner would have crashed Production. It constructed PublicBaseUrlSetting, which throws outside Development when the key is unset. That setting is resolved lazily today, only by the two request-scoped services that mint links. Worse, Main catches it into a Log.Fatal and returns 0, so the container would exit cleanly and every crash-loop restart would look like a healthy stop.

A fallback endpoint has neither problem: routing reaches it only after every real endpoint and every earlier branch has declined, so the special case disappears instead of needing an allowlist that would rot.

Known limitation

A path that matches a route template with the wrong HTTP method still answers 401, not 405 — routing selects the framework's method-rejection endpoint, which carries empty metadata and so meets the FallbackPolicy. Same bug class, rarer, not addressed here.

Test plan

• UnroutedRequestE2ETests (5) over the real HTTP surface — including that a matched endpoint is still challenged, so the FallbackPolicy is not weakened
• The_not_found_answer_does_not_swallow_branch_mounted_paths — reverting to the middleware form reds it, confirming it catches the design the review rejected
• E2E 185/185 · Unit 6510/6510 · Integration 2748/2748