Editor-managed marketing redirects via CMS collection

[Jan0707]

Context

Discussed in #183 (consolidating vanity-host redirects). That PR lands all redirects in either vercel.json (static, at the edge) or middleware (dynamic). These are structural redirects — they don't change.

The redirect pattern that does churn but doesn't exist today is editor-driven marketing short URLs, e.g. /wjax2026 → campaign landing. There are none today, but it's the natural next request from editors and we should be set up to handle it without code changes.

Proposal

Add a Redirects collection in Directus with a tiny schema:

• from — path on programmier.bar (e.g. /wjax2026)
• to — destination URL
• permanent — boolean, default true

Build step reads the collection during Vercel build and splices the entries into vercel.json after the structural block (so editor entries can't accidentally override the vanity-host catch-alls or the /api/ guard). CMS webhook → Vercel deploy hook makes a redirect change live ~3 minutes after publish.

The resulting vercel.json would have two clearly-labelled sections:

1. Structural redirects — hand-edited in code (vanity hosts, /konferenzen rename, the /api/ guard pattern). Engineering owns this.
2. Marketing redirects — rendered from the CMS collection at build time. Editors own this.

Why not Edge Config / runtime

Vercel Edge Config would give true runtime dynamism (no rebuild), but it requires reading from middleware — which puts the redirect back behind ISR's CDN cache, the exact problem #183 fixes. For marketing short URLs the ~3-minute build-and-deploy latency is fine; reintroducing the cache problem isn't.

Why not put the structural redirects in CMS too

• They're load-bearing for the SPA (see Skip /api/ in conference & flutterday redirect middleware #182 / Consolidate vanity-domain redirects into one guarded middleware #183 — the discount-validation outage was caused by exactly this class of rule misbehaving).
• They have nuance (host predicates, negative-lookahead path exclusions, UA branching) that doesn't map to a friendly form schema.
• They don't change.

Exposing raw regex / has clauses to editors is no nicer than editing vercel.json directly, and the blast radius of a bad entry is higher than the convenience is worth.

Acceptance criteria

• Redirects collection exists in Directus with the schema above.
• Build step reads the collection and emits a merged vercel.json with structural rules preserved.
• CMS edits trigger a Vercel rebuild via webhook.
• vercel.json template has clearly delimited structural / generated sections.
• Editor entries cannot override structural rules (generator appends, doesn't merge).
• Graceful behavior if Directus is unreachable during build (fail loud, don't ship an empty redirects list).

Out of scope

• Per-host marketing redirects. The collection assumes apex-host short URLs only.
• Conditional / UA-based marketing redirects.
• Anything that would require middleware at runtime.