refactor: 각 어댑터터별 리펙토링 진행

docs/jpa/repository-adaptation.md

@@ -85,7 +85,7 @@ in a fail-closed contract (`verifyJpaReadinessRegistry` in `src/build.gradle`).
 |---|---|
 | `test` | `src/test` — hermetic unit lane, `./gradlew :adapter:outbound:persistence-jpa:test` |
 | `contractTest`, `integrationTest`, `migrationTest`, `failureTest`, `compatibilityTest` | `src/postgresqlIntegrationTest` — real PostgreSQL containers; selected by the `jpaPlatform*` Gradle tasks |
-| `performanceTest` | `src/jpaPlatformPerformanceTest` — machine-dependent bounds, never part of `check` |
+| `performanceTest` | `src/jpaPlatformPerformanceTest` — pool and `REQUIRES_NEW` connection behaviour, run by `jpaPlatformPoolContractTest`; never part of `check`. The source set keeps the plan's name; the lane asserts behaviour rather than measuring, and no numeric performance bound is claimed anywhere from it. |
 
 Docker-dependent lanes fail closed rather than skipping, matching the existing
 `PostgreSqlReadinessSupport.assertDockerAvailable()` convention in this leaf.

docs/jpa/support-matrix.md

@@ -10,6 +10,20 @@ major changed nothing so long as the string survived somewhere in the document.
 declares a support level per major as a field, each gate names the Gradle task that produces its
 evidence, and this document describes what the registry says.
 
+Being a rendering used to be a claim rather than a mechanism: the tables below were still typed by
+hand, so a major demoted in the registry stayed Stable here and kept its full release job.
+`JpaReleaseRenderingTest` now compares the database table, the gate table and `jpa-release.yml`'s
+matrix and promotion lists to the registry, and `verifyJpaReleaseGateTasks` resolves every gate's
+task against the real Gradle task graph. Edit the registry; these tables follow, or the build fails.
+
+Two renderings stayed outside that comparison until they were added to it. `jpa-nightly.yml` runs
+its own matrix and nothing checked it, so a demotion corrected the release lane and left the nightly
+lane certifying the major. And an Experimental major's "compatibility lane only" named no file: the
+lane existed, but the registry, this document and the release workflow could each be read end to end
+without establishing that, so a reader looking for it concluded there was none. An Experimental major
+now has to be recorded as the target of a lane in `.github/workflows`, and a Stable lane may not run
+it.
+
 ## Database
 
 | Database | Support | Evidence |
@@ -17,7 +31,7 @@ evidence, and this document describes what the registry says.
 | PostgreSQL 16 | Stable | full contract suite, release lane (own matrix job) |
 | PostgreSQL 17 | Stable | full contract suite, release lane (own matrix job) |
 | PostgreSQL 18 | Stable | full contract suite, release lane (own matrix job) |
-| PostgreSQL 19 | Experimental | compatibility lane only; promotion requires an ADR |
+| PostgreSQL 19 | Experimental | [`jpa-next-postgresql19.yml`](../../.github/workflows/jpa-next-postgresql19.yml) — `NOT_EXECUTABLE`: no `postgres:19-alpine` is published, so no container of that major has been started; promotion requires an ADR |
 | H2 | Local convenience | **never** evidence of PostgreSQL behaviour |
 
 Each major gets its **own release job**, because for a while it did not. The release lane passed
@@ -82,6 +96,8 @@ the difference visible instead of asserting a constant against itself. See
 | PostgreSQL `COPY` | Admin (J4) |
 | Hibernate second-level cache | Advanced |
 | Hibernate Envers | Advanced |
+| Technical auditing — `audit/AuditableEntity` | Stable (canonical) |
+| Technical auditing — `auditing/AuditMetadata` | Candidate, not composed |
 | Multi-tenancy (column, RLS, schema, database) | Experimental |
 | Consistency-aware read replica | Experimental |
 
@@ -98,6 +114,26 @@ Each row is a way the platform could pass its tests and still be wrong in produc
 | `runtime-role-no-ddl` | gate | the application's own credential being able to alter or drop schema objects |
 | `collection-fetch-pagination` | gate | a paged collection fetch silently reading the whole table and paginating in memory |
 
+### The two audit mechanisms
+
+`audit/AuditableEntity` is the canonical one: `created_*`/`updated_*`, a 256-character actor,
+stamped explicitly by the repository adapter. It is what the sample entities extend and what the
+migrations were written for.
+
+`auditing/AuditMetadata` is a second, complete mechanism with different column names
+(`modified_*`), a different actor length (64) and a different capture lifecycle (Spring Data
+listeners). Nothing embeds it and nothing composes `JpaAuditingConfiguration`, which is why it is
+listed as a candidate rather than as a capability: promoting it means choosing between reshaping it
+to the canonical columns and writing a forward migration for the new ones, and that choice has not
+been made. Until it is, an entity picks one mechanism or none — enforced on the production graph by
+`JpaAuditMechanismRule.entitiesUseExactlyOneAuditMechanism`.
+
+Neither mechanism reaches a bulk or native update. Both stamp on an ordinary save — one in the
+adapter, one on a managed entity's lifecycle — so a statement that goes straight to the database
+leaves the audit columns showing the previous save. A bulk update of an audited entity must
+therefore set the audit column in the statement, which
+`JpaAuditMechanismRule.bulkUpdatesOfAuditedEntitiesStampAudit` checks over the production graph.
+
 ## Explicitly unsupported
 
 - Reactive JPA. JPA is a blocking specification; a reactive facade over it moves the blocking call