Dialect conformance suite: one shared repository test suite run per dialect, instead of seven copies

[zantvoort]

Problem

Every dialect module carries its own copy of the same integration suite: EntityRepositoryTest, PolymorphicTest, SchemaValidatorTest and MultiColumnExpressionTest exist seven times (storm-h2, -postgresql, -mysql, -mariadb, -mssqlserver, -oracle, -sqlite), 20,024 lines in total, 70 to 99% identical line for line once the dialect names are normalized (IntegrationConfig and TestSpringConnectionProvider are byte-identical in all seven).

The copies have drifted, and that is the actual cost. Across the seven EntityRepositoryTest classes there are 117 distinct test methods; only 24 run on all seven dialects. Per module, the number of union methods missing:

module	methods	missing from this dialect
storm-postgresql	82	35
storm-mysql	80	37
storm-mariadb	84	33
storm-mssqlserver	84	33
storm-oracle	80	37
storm-h2	61	56
storm-sqlite	34	83

So a repository behavior verified on MariaDB may be unverified on PostgreSQL, and a fix that adds a test to one copy leaves the others behind. That is the opposite of what 1.14 set out to be about ("SQL that is correct on every dialect rather than on the permissive ones"): the dialect suite is where a dialect regression should be caught, and it is the least uniform part of the test base.

Proposal

One shared suite that every dialect runs, with dialect-specific tests kept where they belong:

• A storm-dialect-tck (or a test-jar of storm-core's test sources) holding abstract AbstractEntityRepositoryConformanceTest, AbstractPolymorphicConformanceTest, AbstractSchemaValidatorConformanceTest, AbstractMultiColumnExpressionConformanceTest, parametrized by the DataSource (and the schema script) the dialect module supplies.
• Each dialect module keeps a thin subclass per suite that provides the container and schema, plus its genuinely dialect-specific tests (MySQLDialectResolutionTest, MSSQLServerGroupByIdentityTest, PostgreSQLJsonTest, and so on), which are the parts that differ today for a reason.
• Where a dialect legitimately cannot support a behavior, the shared test states it (assumeTrue(dialect.supportsX()) or an overridable hook), so the exception is visible in one place instead of being an absent copy.
• The container setup can use @StormTest(database = ...) from Run @StormTest against a real database with Testcontainers #502 or the existing @DataJpaTest + Testcontainers wiring, whichever keeps the JPA-backed tests intact.

Migration order: extract the union of the seven EntityRepositoryTest copies first (it is where the drift is largest), run it on all seven and fix or assume the deltas that surface, then the three smaller suites.

Notes

• Test-only refactor; no API change. It reduces the test base by roughly 15,000 lines while raising the number of behaviors every dialect verifies from 24 to the full union.
• Related duplication elsewhere is small and mostly deliberate (the Jackson 2/3 twins; the Kotlin plain vs Spring transaction suites at 84% similarity could share a base the same way, but that is one pair, not seven).
• Coverage attribution across modules is handled separately by ci: read coverage from an aggregate JaCoCo report #513 (aggregate report); this issue is about the tests themselves.