Consistente _TEST/_PRODUCTION postfix voor omgevingsspecifieke Gitea variables

Hernoemt de Gitea-variable achter VITE_UMAMI_WEBSITE_ID naar
VITE_UMAMI_WEBSITE_ID_TEST, zodat deze consistent is met
VITE_UMAMI_WEBSITE_ID_PRODUCTION en DEPLOY_PATH_TEST/DEPLOY_PATH_PRODUCTION.
De Vite build-time envvar-naam die de app zelf verwacht
(VITE_UMAMI_WEBSITE_ID) verandert niet, alleen de naam van de Gitea
repository variable erachter. Bewust gedeelde variabelen (VITE_UMAMI_SCRIPT_URL,
VITE_SENTRY_DSN, PI_MAIN_* secrets) krijgen geen postfix, want die zijn
geen omgevingsspecifieke waarden. Documentatie in umami-setup.md,
deployment-instructions.md en monitoring-plan.md bijgewerkt.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md

@@ -192,7 +192,7 @@ verschillende domeinen en horen dus niet in dezelfde statistieken te belanden:
    - Name: `SLP Software (test)` (of naar keuze)
    - Domain: `test.slpsoftware.nl`
 3. Na het opslaan toont Umami een **Website ID** (een UUID) voor deze entry — nodig voor
-   `VITE_UMAMI_WEBSITE_ID` in de volgende stap.
+   `VITE_UMAMI_WEBSITE_ID_TEST` in de volgende stap.
 4. Herhaal stap 2-3 voor productie zodra die omgeving wordt opgezet: een tweede website-
    entry met Domain `slpsoftware.nl`, met een eigen Website ID voor
    `VITE_UMAMI_WEBSITE_ID_PRODUCTION`.
@@ -201,20 +201,25 @@ verschillende domeinen en horen dus niet in dezelfde statistieken te belanden:
 De React-app (`src/components/UmamiAnalytics.tsx`) injecteert het Umami tracking-script
 automatisch, mits de volgende build-time variabelen zijn ingesteld — geen van deze zijn
 **secrets** (client-side zichtbaar), dus als Gitea Actions **repository variables**
-(niet secrets), net als `VITE_SENTRY_DSN`:
+(niet secrets), net als `VITE_SENTRY_DSN`. Omgevingsspecifieke variabelen (die per
+omgeving een andere waarde hebben) krijgen consistent een `_TEST`/`_PRODUCTION`-postfix;
+gedeelde variabelen (die bewust voor beide omgevingen identiek zijn) niet:
 
 | Variabele | Waarde |
 |---|---|
-| `VITE_UMAMI_SCRIPT_URL` | `https://analytics.slpsoftware.nl/script.js` (gedeeld tussen test en productie — zelfde Umami-instance/endpoint voor beide) |
-| `VITE_UMAMI_WEBSITE_ID` | het Website ID van de **test**-website-entry uit stap 4 |
+| `VITE_UMAMI_SCRIPT_URL` | `https://analytics.slpsoftware.nl/script.js` (gedeeld tussen test en productie — zelfde Umami-instance/endpoint voor beide, geen postfix) |
+| `VITE_UMAMI_WEBSITE_ID_TEST` | het Website ID van de **test**-website-entry uit stap 4 |
 | `VITE_UMAMI_WEBSITE_ID_PRODUCTION` | het Website ID van de **productie**-website-entry uit stap 4 (pas nodig vóór de eerste `deploy_production`-run) |
 
 Stel deze in via **Gitea → Repository Settings → Actions → Variables**. Zodra ze bestaan,
 pakt de eerstvolgende build ze automatisch op; zonder deze variabelen slaat de app het
-inladen van het script gewoon over (geen crash, geen tracking). Let op:
-`continuous_integration.yaml`'s `build`-job (test) leest `VITE_UMAMI_WEBSITE_ID`, de
-`build-production`-job leest `VITE_UMAMI_WEBSITE_ID_PRODUCTION` — verwissel deze niet,
-anders komt productieverkeer in de teststatistieken terecht (of andersom).
+inladen van het script gewoon over (geen crash, geen tracking). Let op: dit zijn de
+namen van de Gitea-variabelen — de app zelf verwacht altijd de envvar-naam
+`VITE_UMAMI_WEBSITE_ID` (zie `UmamiAnalytics.tsx`), dus in `continuous_integration.yaml`
+wordt bv. `VITE_UMAMI_WEBSITE_ID: ${{ vars.VITE_UMAMI_WEBSITE_ID_TEST }}` gebruikt in de
+`build`-job en `VITE_UMAMI_WEBSITE_ID: ${{ vars.VITE_UMAMI_WEBSITE_ID_PRODUCTION }}` in
+`build-production` — verwissel deze niet, anders komt productieverkeer in de
+teststatistieken terecht (of andersom).
 
 **Lokaal (`pnpm dev`)**: het tracking-script wordt hier bewust nooit geladen (zie
 `UmamiAnalytics.tsx`), zodat lokaal testen de bezoekersstatistieken niet vervuilt. Wil je
@@ -229,7 +234,7 @@ dit toch lokaal testen, zet dan tijdelijk beide waarden in `.env.local` (zie
 - [ ] DNS-record + certbot voor `analytics.slpsoftware.nl` op de reverse-proxy-Pi.
 - [ ] Standaard Umami-wachtwoord direct wijzigen na eerste login.
 - [ ] Website aanmaken in Umami voor de testomgeving en het Website ID overnemen.
-- [ ] `VITE_UMAMI_SCRIPT_URL` en `VITE_UMAMI_WEBSITE_ID` als Gitea repository variables instellen.
+- [ ] `VITE_UMAMI_SCRIPT_URL` en `VITE_UMAMI_WEBSITE_ID_TEST` als Gitea repository variables instellen.
 - [ ] Zodra productie wordt opgezet: aparte website aanmaken in Umami voor `slpsoftware.nl` en het Website ID als `VITE_UMAMI_WEBSITE_ID_PRODUCTION` instellen (zie stap 4/5 hierboven — vereist vóór de eerste `deploy_production`-run).
 
 ## Vervolgstappen voor toekomstige self-hosted diensten