Rond Sentry logging-follow-up af: bevestigd werkend, documentatie bijgewerkt

Co-authored-by: Junie <junie@jetbrains.com>

aidlc-docs/features/react-frontend/operations/monitoring/monitoring-plan.md

@@ -27,7 +27,7 @@ A combination of:
 - **Reuse of existing infrastructure**: this feature does not plug into any pre-existing shared monitoring (original Question 7 = A) — there is none yet. Should a shared back-end/CMS monitoring stack be introduced later, this can be revisited.
 
 ## Open Action Items
-1. ~~Decide logging destination~~ — **Resolved**: Sentry free tier, wired into `ErrorBoundary`/`main.tsx` (see `monitoring-setup.md`). The Gitea Actions variable `VITE_SENTRY_DSN` still needs to be created by the user with a real Sentry project DSN; until then the build simply skips Sentry initialization and only console-logging is active.
+1. ~~Decide logging destination~~ — **Resolved and verified**: Sentry free tier, wired into `ErrorBoundary`/`main.tsx` (see `monitoring-setup.md`), including tracing, environment/release tags, and a tunnel to bypass ad-blocker blocking. The user confirmed errors, logs, and metrics are received correctly, both locally and on the test environment. The Gitea Actions variable `VITE_SENTRY_DSN` still needs to be created by the user with a real Sentry project DSN for the test/production build; until then that build simply skips Sentry initialization and only console-logging is active (local development already has its own DSN via `.env.local`).
 2. **Pick concrete analytics + uptime tools**: `monitoring-setup.md` lists candidate free-tier tools; final tool selection/account creation is a manual follow-up outside this workflow (no code changes required to swap providers, since neither is wired into the codebase yet beyond an optional embed snippet).
 
 ## Rationale

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

@@ -69,7 +69,7 @@ Pick one:
 
 | Concern | Approach | Status |
 |---|---|---|
-| Client-side errors | Logging (console + Sentry free tier) | Implemented; `VITE_SENTRY_DSN` Gitea variable still needs to be created by the user |
+| Client-side errors | Logging (console + Sentry free tier, incl. tracing, environment/release tags, and an ad-blocker-proof tunnel) | Implemented and confirmed working end-to-end (errors, logs, and metrics received) locally and on the test environment; the `VITE_SENTRY_DSN` Gitea repository variable still needs to be created by the user for the test/production build to report to Sentry (local already works via `.env.local`) |
 | Visitor/usage insight | Analytics dashboard (Plausible/Umami/GA4) | Tool selection open item |
 | Site reachability | Uptime dashboard (UptimeRobot/Better Uptime) | Tool selection + production URL open item |
 | Alerting | Out of scope | Not configured |

aidlc-docs/features/react-frontend/operations/production-readiness-checklist.md

@@ -19,6 +19,6 @@
 - **Ready for Production**: Yes with caveats
 - **Open Follow-ups**:
   - Finalize the hosting/domain setup and extend `.gitea/workflows/deploy.yml`'s `deploy` job to actually upload `dist/` to the host, instead of only packaging it as a downloadable artifact (see `deployment-plan.md` "Open Item")
-  - ~~Decide the client-side error logging destination~~ — **Resolved**: console + Sentry free tier, implemented (see `monitoring-setup.md`); remaining manual step is creating the `VITE_SENTRY_DSN` Gitea Actions variable
+  - ~~Decide the client-side error logging destination~~ — **Resolved and verified**: console + Sentry free tier, implemented and confirmed working end-to-end (errors, logs, metrics) locally and on the test environment, including tracing, environment/release tags, and an ad-blocker-proof tunnel (see `monitoring-setup.md`); remaining manual step is creating the `VITE_SENTRY_DSN` Gitea Actions variable for the test/production build
   - Pick and configure the concrete analytics tool (e.g. Plausible/Umami/GA4) and uptime dashboard tool (e.g. UptimeRobot/Better Uptime), including registering the final production URL once hosting is finalized
   - Run a formal Lighthouse performance check before the first real production deployment (flagged as not yet run in `build-and-test-summary.md`)