Splits Umami website-ID per omgeving in productie-build (was per ongeluk gedeeld)

build-production hergebruikte vars.VITE_UMAMI_WEBSITE_ID van de testbuild,
maar Umami-website-ID's horen bij één specifieke domeinentry in het
dashboard. Zonder deze fix zou productieverkeer in de teststatistieken
terechtkomen. Introduceert VITE_UMAMI_WEBSITE_ID_PRODUCTION als losse Gitea
variable, en documenteert dat er twee aparte Umami-website-entries nodig
zijn (test.slpsoftware.nl / slpsoftware.nl). VITE_UMAMI_SCRIPT_URL en
VITE_SENTRY_DSN blijven bewust gedeeld tussen omgevingen.

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

aidlc-docs/features/react-frontend/operations/deployment/deployment-instructions.md

@@ -74,7 +74,10 @@ Productie deployt **nooit** automatisch bij een push naar `master` — alleen vi
 4. Vink **`deploy_production`** aan voordat je de run start.
 5. Dit triggert naast de gebruikelijke `build`/`test`/`deploy-test` ook `build-production` en `deploy-production`.
 
-Vereist eenmalig vooraf: de Gitea-variable `DEPLOY_PATH_PRODUCTION` (zie boven) en de productie-nginx/SSL-configuratie + webroot-map op de Pi's (zie "Eenmalige Setup — Domeinnaam & DNS").
+Vereist eenmalig vooraf:
+- De Gitea-variable `DEPLOY_PATH_PRODUCTION` (zie boven).
+- De Gitea-variable `VITE_UMAMI_WEBSITE_ID_PRODUCTION` (zie `umami-setup.md` stap 4/5) — zónder deze wordt productieverkeer per ongeluk meegeteld bij de teststatistieken.
+- De productie-nginx/SSL-configuratie + webroot-map op de Pi's (zie "Eenmalige Setup — Domeinnaam & DNS").
 
 ## Verifying a Deployment
 1. Bevestig dat de Gitea Actions run succesvol is (alle relevante jobs groen — `deploy-test` altijd, `build-production`/`deploy-production` alleen als je `deploy_production` had aangevinkt).