feat(jpa): implement the JPA relational persistence platform

Implements the Stable and Experimental JPA persistence platform designs
against real PostgreSQL, adapted to this repository's fail-closed 19-leaf
registry.

The design models the platform as 25 Gradle projects. `src/settings.gradle`
throws unless the registry holds exactly 19 leaves, so the plan's modules
become packages inside `:adapter:outbound:persistence-jpa` (starter in
`:app-bootstrap`, testkit in its own source set). The full mapping, the
renames this repository's naming gate required, and every deliberate
substitution are recorded in `docs/jpa/repository-adaptation.md`.

Seven Docker-backed lanes replace the plan's seven JVM test suites. Each
fails closed: a lane that discovers nothing, or a container that cannot
start, is an error rather than a skip.

Three defects the contracts found against a real server:

- `CommitFailureClassifier` treated only SQLSTATE 40003, class 08, and
  transport breaks as completion-unknown. A backend terminated mid-commit
  reports 57P01, and the commit record may already be in the WAL — so a
  possibly-committed transaction could be re-run. 57P01/57P02/57P03 now
  classify as completion-unknown.
- `SchemaTenantMigrationOrchestrator` recorded `MigrateResult`'s target
  version, which is empty for a tenant already current, reporting migrated
  tenants as unmigrated during a partial rollout. It now reads the applied
  version back from the tenant's schema history.
- `JpaStreamExecutor` checked only the declared return type for reactive
  publishers, and `RegisteredPostgreSqlCopyLoader` passed the COPY timeout
  to `SET`, which is parsed before parameter binding.

`JpaModuleBoundaryTest` enforces the plan's module map as package rules;
`verifyCleanArchitectureDependencies` governs edges between leaves and
cannot see these. Its first assertion is that the import is non-empty,
because every rule under it is a `noClasses()` rule and would pass
vacuously on an empty import.

Verified: 128 container tests across all seven lanes, 1183 unit tests,
`:adapter:outbound:persistence-jpa:check`, `:app-bootstrap:check`,
`verifyCleanArchitectureDependencies`, `verifyOneTypePerFile`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

infra/jpa/postgres/README.md

@@ -0,0 +1,39 @@
+# infra/jpa/postgres
+
+Server-side settings the JPA platform's contracts assume, and why each one matters.
+
+The contract suites start their own containers through
+`dev.caskeleton.adapter.outbound.persistence.testkit.postgresql.PostgreSqlContainerFactory`, so
+nothing here is needed to run them. This directory records what a *deployed* PostgreSQL has to look
+like for the platform's guarantees to hold, because several of them are server settings rather than
+application code.
+
+## Settings the platform depends on
+
+| Setting | Why the platform cares |
+|---|---|
+| `statement_timeout` | The last bound on a runaway statement. The platform sets transaction timeouts, but a single statement inside a transaction can still outlive the request that asked for it. |
+| `idle_in_transaction_session_timeout` | An idle open transaction holds its locks and its snapshot indefinitely, which blocks writers and prevents vacuum. This is what turns "someone left a transaction open" into a bounded incident. |
+| `lock_timeout` | A cluster-wide floor under the per-request lock bounds in `PostgreSqlLockOptions`. |
+| `max_connections` | The number `app.jpa-platform.datasource.maximum-pool-size` must be sized against — across every instance, and allowing for `REQUIRES_NEW` taking a second connection while pinning the first. |
+| `default_transaction_isolation` | Left at `read committed`. The platform selects `repeatable read` or `serializable` per transaction profile; changing the default would silently change every transaction that did not ask. |
+
+## Suggested baseline
+
+```conf
+statement_timeout = '30s'
+idle_in_transaction_session_timeout = '60s'
+lock_timeout = '10s'
+default_transaction_isolation = 'read committed'
+```
+
+These are starting points, not recommendations: the right `statement_timeout` depends on the
+slowest legitimate query in the application, and setting it below that turns a working report into
+an error. Measure before pinning.
+
+## What is deliberately not configured here
+
+- **Roles.** Credential separation lives in [`../roles/runtime-roles.sql`](../roles/runtime-roles.sql).
+- **Schema.** Flyway owns it (design §31). Nothing in this directory creates a table.
+- **Extensions.** The platform's PostgreSQL support — JSONB, arrays, ranges, `SKIP LOCKED`,
+  `ON CONFLICT` — is all core PostgreSQL. No extension is required, and none should be assumed.

infra/jpa/roles/runtime-roles.sql

@@ -0,0 +1,54 @@
+-- Runtime / migration / admin credential separation for the JPA persistence platform.
+-- Design §36; enforced at startup by PostgreSqlRuntimeRoleVerifier + DatabaseRolePolicy.
+--
+-- The separation is what makes "Flyway owns schema change" enforceable rather than aspirational.
+-- If the application's own credential cannot execute DDL, then no code path, no library, and no
+-- injected statement can alter the schema at runtime — regardless of what the application intended.
+--
+-- Run as a superuser once per database. Replace the placeholder passwords with values from the
+-- deployment's secret store; they are intentionally not committed.
+
+-- 1. The schema the application owns. Owned by the migration role, not the runtime role.
+create schema if not exists app authorization app_migration;
+
+-- 2. Roles.
+--    app_migration : owns the schema, applies Flyway migrations. DDL.
+--    app_runtime   : the application's credential. DML only, no DDL, no CREATE.
+--    app_admin     : J4 operations — COPY, backfill, maintenance. Never used by request paths.
+create role app_migration login password 'REPLACE_FROM_SECRET_STORE';
+create role app_runtime   login password 'REPLACE_FROM_SECRET_STORE';
+create role app_admin     login password 'REPLACE_FROM_SECRET_STORE';
+
+-- 3. Revoke the PUBLIC grants that make the checks in DatabaseRolePolicy necessary.
+--    Before PostgreSQL 15, PUBLIC held CREATE on the public schema — which is how an unprivileged
+--    role ends up able to plant an object that shadows a real one through search_path.
+revoke all on database current_database() from public;
+revoke create on schema public from public;
+
+-- 4. Runtime: read and write rows in the application schema. Nothing else.
+grant connect on database current_database() to app_runtime;
+grant usage on schema app to app_runtime;
+grant select, insert, update, delete on all tables in schema app to app_runtime;
+grant usage, select on all sequences in schema app to app_runtime;
+
+-- Tables created by future migrations must inherit the same grants, or the first deployment after
+-- a new table silently fails at runtime with a permission error.
+alter default privileges for role app_migration in schema app
+    grant select, insert, update, delete on tables to app_runtime;
+alter default privileges for role app_migration in schema app
+    grant usage, select on sequences to app_runtime;
+
+-- 5. Explicitly deny the two privileges the startup verifier checks for.
+revoke create on schema app from app_runtime;
+revoke create on database current_database() from app_runtime;
+
+-- 6. Admin: bulk operations under an audited identity, still without schema ownership.
+grant connect on database current_database() to app_admin;
+grant usage on schema app to app_admin;
+grant select, insert, update, delete on all tables in schema app to app_admin;
+alter default privileges for role app_migration in schema app
+    grant select, insert, update, delete on tables to app_admin;
+
+-- 7. Pin the runtime search_path so an unqualified name cannot resolve anywhere unexpected.
+alter role app_runtime set search_path = app, pg_catalog;
+alter role app_admin   set search_path = app, pg_catalog;

infra/jpa/toxiproxy/docker-compose.yml

@@ -0,0 +1,43 @@
+# Commit-ambiguity failure injection for the JPA platform (design §39).
+#
+# The suite needs a proxy rather than a kill switch because the scenario that matters cannot be
+# produced any other way. Stopping the container, killing the process, or closing the client socket
+# all break *before* the server commits — the easy case, where the transaction rolled back and the
+# use case may simply be re-run. The hard case is a commit the server completed whose
+# acknowledgement never came back, and it only exists if you can cut the return path while leaving
+# the forward path intact.
+#
+# That is what CommitAmbiguityProxy does with a downstream-only toxic, and it is the one scenario
+# that distinguishes a platform that reports completion-unknown from one that retries a write which
+# already succeeded.
+#
+# Ordinary contract runs use Testcontainers and do not need this file; it exists for reproducing a
+# failure scenario by hand.
+
+services:
+  postgres:
+    image: postgres:16-alpine
+    environment:
+      POSTGRES_DB: jpa_failure
+      POSTGRES_USER: jpa_failure
+      POSTGRES_PASSWORD: jpa_failure
+    # No published port: the suite must reach PostgreSQL only through the proxy, or the injected
+    # fault can be bypassed by connecting directly and the test passes without testing anything.
+    expose:
+      - "5432"
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U jpa_failure -d jpa_failure"]
+      interval: 2s
+      timeout: 3s
+      retries: 30
+
+  toxiproxy:
+    image: ghcr.io/shopify/toxiproxy:2.11.0
+    depends_on:
+      postgres:
+        condition: service_healthy
+    ports:
+      # 8474 is the control API the suite drives; 8666 is the proxied PostgreSQL port.
+      - "8474:8474"
+      - "8666:8666"
+    command: ["-host", "0.0.0.0"]