Plan and create a safe synthetic identity test fixture

## Outcome Replace the production-data development/test fixture with a small, reproducible, isolated identity fixture suitable for safely exercising user setup and the port's API/OIDC/browser flows. ## Approved implementation scope Owner approved a fully synthetic fixture and destruction of every local restored production database/copy, retaining the private dump file only. Inventory local identity databases and remove their cluster storage once the dedicated scope is verified; do not touch unrelated project databases. Build a fresh small fixture using pinned Go bootstrap or schema-only structure with entirely synthetic seed data, fresh test-only credentials/keys, local callbacks and isolated mail. Never restore production data. Add fail-closed fixture identity/connection checks before enabling database-backed test/server execution. Record fixture provenance and verification separately from historical production compatibility. ## Safety restriction The existing test database has roughly 4,000 real users and real SMTP credentials. Running Rust/pinned Go servers, browser harnesses, or DB-backed tests against it, its dump/restores or its clones is prohibited. Disposable clones are not a substitute for removing real data and secrets. ## Confirmed construction and removal Removed the dedicated restored-data PostgreSQL container and its volume, plus two orphaned identity PostgreSQL volumes identified by database/schema catalogs. Read-only host inventory found no ZITADEL schemas; unrelated moeteadm/project databases and volumes remain untouched. Kept the private production dump with its recorded SHA-256 unchanged and removed the production-derived local connection/master-key/PAT settings. Replacement is bootstrapped from the attested pinned Go binary against an empty labelled volume and internal Docker network, never from the dump. Go stops before Rust seed writes. It currently has 11 entirely synthetic users (10 humans and one service user), two organizations, fresh master/encryption/signing keys and PAT/passwords, a synthetic public OIDC client with localhost callback/logout URIs, and zero SMTP/SMS providers. Native tooling connects through a private Unix socket rather than opening the database network to publish a port. Source schema fingerprint is `37a8dba2d991ac4041bb6caba9d401a71af55c65a77cbb75fda4641203d29e4e` with 2,128 catalog items; obsolete production projection structures are absent, so this is not the production fingerprint. Startup/testing guards require the synthetic database/role, a matching builder-issued database-comment nonce and pinned baseline, fake email domains and safe callbacks/providers. Completed source/clone guards, fail-closed old-database and remote-SMTP startup refusal, wrong-marker/real-callback negative tests, synthetic-only CI bootstrap and cleanup, and reproducible reset/destruction. Interactive identity and Mailpit share an internal Docker network namespace; a real outbound TCP attempt is blocked. Host ingress is loopback-only via bounded proxy targets on that internal network, and native tests use the private PostgreSQL Unix socket. Diagnostic compose RP shares the same isolated namespace. Formatting, strict all-target/all-feature Clippy, 108 default tests and all 43 explicitly enabled synthetic database tests pass, including repository/API/admin/OIDC/real-Ruby contracts and pinned-Go restart/readback. Chrome follows real Mailpit setup links, tests all three locales/policy boundaries/mobile layout/replay/notifications/direct-password readiness, and completes actual diagnostic RP login/code exchange/userinfo/logout/re-authentication on localhost. Browser-wide script disabling and independent browser inspection of server-side JWKS internals remain unverified; HTTP/protocol tests cover those boundaries. CI workflow is updated but remote runner execution is unverified. Production real-data execution remains prohibited and these synthetic gates do not replace production cutover checks. Left only the clean 11-user synthetic baseline running in the PostgreSQL container. Identity, Mailpit, RP, bootstrap and proxy processes are stopped. The private dump checksum remains unchanged; no restored production cluster or identity orphan volumes remain. Implementation and documentation are committed in `14a4d3b` (`feature: Add user setup and isolated synthetic fixtures`). Private credentials/dump/build state are excluded. The working tree is clean; the isolated synthetic owner-testing environment is running with the clean baseline. ## Acceptance criteria - A minimal representative set of entirely fake instances, organizations, users, roles and OIDC clients; no real personal data, immutable historical production payloads, sessions or tokens. - Fresh test-only encryption/signing keys, master key, PATs and passwords; no production SMTP/SMS/webhook/other provider credentials. - Callback/logout/client and notification destinations constrained to loopback or reserved test domains; actual delivery goes only to an isolated mail sink and outbound network access is denied. - Production-compatible schema without Rust migrations; record fixture provenance/fingerprint without treating it as a production cutover verification. - Explicit fixture identification/connection safeguards prevent accidental use of the current real-data database. Replace local settings and CI fixture inputs only after approval and verification. - Reproducible seed/reset/cleanup, documented safe test commands, then rerun setup/API/OIDC/browser and relevant pinned-Go gates against the approved fixture.