Consent gate for consent-requiring analytics providers #594

Prerequisite for the consent-requiring providers in #486 (Google Analytics 4, Adobe Analytics, Microsoft Clarity, Meta Pixel, Hotjar). Those set cookies or fingerprint, so under GDPR they may not load before the visitor agrees.

The gate must be invisible unless it is needed. It renders only when the configured analytics.provider is marked consent: required. A default install has no banner, and neither does one using the cookieless providers (Plausible, Umami, GoatCounter, Fathom, Matomo, Pirsch, Cloudflare). The built-in counter stays cookieless and outside the gate.

What it has to do

• Block script injection until acceptance — not load-then-disable. A gtag.js that has already run has already set its cookies.
• Persist the decision client-side (a first-party cookie or localStorage), including a decline, so the banner does not reappear on every page.
• Offer a genuine refusal, equally reachable as acceptance. A banner with only an "OK" is not consent.
• Let the visitor revoke later — a link in the footer next to Impressum is the natural place, and legal.enabled already gates that area.
• Stay accessible: focus trap while open, escapable, readable in both themes, and not a layout-shift bomb on mobile.

Fits the existing structure

Footer.tsx already carries the Impressum link behind legal.enabled; revocation belongs there. The gate text needs entries in lib/i18n/locales/{en,de}.ts — it is visitor-facing copy, so it must be translatable, not hardcoded.

Acceptance

• No consent-requiring provider configured: nothing renders, no storage is written.
• Provider configured, nothing decided yet: no third-party script in the DOM, no third-party cookie set.
• After acceptance: script loads, decision survives a reload.
• After refusal: still no script, decision survives a reload, and the visitor can change their mind from the footer.

Effort: M.

Split out of #486 so the provider mechanism and the consent flow can be tested independently.