Revert #34: invite and promo links serve the 404 page

[TaprootFreakAI]

EN. #34 made every invite and promo link serve the site's own 404 page instead of the landing. Before it, a shared link rendered the landing and answered 404; since it went live, a visitor following one is shown "page not found". This reverts it. The original defect — the 404 status that keeps share crawlers from reading the meta tags — is back with it, and that is the smaller of the two.

DE. #34 hat dazu geführt, dass Einladungs- und Promo-Links die Fehlerseite ausliefern statt der Einladungsseite. Vorher zeigte ein geteilter Link die richtige Seite, nur mit falschem Status. Seit der Auslieferung sieht ein Besucher "Seite nicht gefunden". Das hier nimmt die Änderung zurück. Der ursprüngliche Fehler kommt damit zurück, ist aber der kleinere von beiden.

What was measured

On production, after #34 went live:

curl -s https://realunit.app/invite/AB12CD | grep title
  ->  <title>Seite nicht gefunden — RealUnit</title>      (2695 bytes, the site's 404 page)

Before #34, the same URL answered 404 with the landing shell and the injected code in its title.

Verified on a preview deployment of this revert:

/invite/AB12CD  ->  404  <title>RealUnit — Einladung AB12CD</title>
/promo/EVT1     ->  404  <title>RealUnit — Promo-Code EVT1</title>
/invite/        ->  200  <title>RealUnit — Einladung</title>

What the cause is not. The first suspicion was the rebuilt GET-equivalent handed to context.next(). A branch that calls context.next() with no argument was deployed to a preview and behaves exactly like #34 does, so that is not it. A probe build shows the path gate returning true and context.next() answering 404 with the site's 404 page for /invite/<code> — the asset lookup no longer resolves the _redirects rewrite. Why #34 changes that is still open, which is the reason this reverts rather than patches.