Define and prove the identity application framework

Establish a coherent internal application framework before implementing a full new identity platform. Confirmed intent: - Build separately from the ZITADEL-compatible Rust port; do not modify its uncommitted work or the running ZITADEL deployment. - No near-term production deployment or migration. Compatibility with ZITADEL's existing schema is not a requirement for the new design. - Prioritize consistent model and controller structure and reliable traceability of state changes. Confirmed foundation direction: - Rust modular monolith using existing HTTP and PostgreSQL libraries rather than a new general-purpose web framework. - Authoritative current-state tables, transactional history/revisions and outbox; core security reads do not depend on asynchronous projections or historical replay. - Feature-oriented modules, explicit domain/input/output types, shared transaction/context/error conventions, thin HTTP controllers, and explicit authorization. - Prove the conventions with a small organization create/update/history slice before adding users, credentials or OIDC. Select the second slice to test reuse before building macros or generic CRUD abstractions. - Use only a fresh synthetic development database and fake identities; do not reuse the port's archived production data or credentials. Acceptance criteria: - Repository name/location, initial stack, framework boundaries and first feature scope are confirmed. - A small runnable foundation demonstrates consistent HTTP-to-command-to-transaction-to-history behavior without protocol implementation. - Validation proves atomic history/state/outbox writes, rollback, authorization denial, concurrent-change handling, tenant isolation where applicable, and intentional audit field selection. - Scope and limitations remain explicit; successful scaffolding does not imply production readiness or a migration plan. Implemented at /home/mathias/work/identity-platform on feature/establish-application-foundation. Cargo generated the package manifest and managed dependencies. Initial scope is one feature-oriented Rust package using Axum/SQLx; template engine selection remains deferred. Organization create/rename/read/history uses explicit domain, database, and HTTP contracts, application authorization, optimistic concurrency, transaction-local context, RLS, and database-enforced history/outbox capture. Runtime role cannot edit history/outbox or bypass capture; startup rejects privileged roles and migration/checksum mismatches. Explicit migration and demo provisioning commands are separate from serving. Verified: formatting, all-target/all-feature strict Clippy, normal unit tests, all eight real-PostgreSQL integration tests plus four unit tests through the dedicated synthetic helper, and standalone executable HTTP smoke covering readiness/create/rename/history/stale-update rejection and graceful shutdown. Database tests include history/outbox fault injection, rollback, concurrency, authorization denial, tenant isolation, runtime privileges, actor validity, snapshot fields, HTTP limits, and schema checks. Development database is a new egress-denied Compose service behind loopback-only unprivileged declarative ingress. Tests create empty databases from template0, never clone or restore fixtures. Interactive services were stopped after validation; no commits or remote changes made. Limitations: local demo authentication only; outbox storage without delivery; no users/credentials/OIDC/UI, general temporal reconstruction, history retention/anonymization, independent tamper evidence, production deployment design, or migration from ZITADEL. The next feature should test reuse before adding macros, generic CRUD, or crate splits. Existing port files and running ZITADEL were not modified.