[magnusp]

What changed

• Adds LibsqlConformanceGuard, which opens the suite's jdbc:sqlite::memory: probe through DriverManager and verifies:
  • the resolved driver reports libSQL JDBC Driver;
  • the resolved database product reports SQLite (libSQL);
  • the live server returns a SQLite source id carrying libSQL's alt1 source-id marker (SELECT sqlite_source_id()).
• Wires the guard into XerialLauncherSessionListener.launcherSessionOpened, after the conformance shim is registered and before any upstream test can run.
• Adds LibsqlConformanceGuardTest covering a valid libSQL connection, a foreign xerial-shaped connection (SQLite JDBC / SQLite), and a non-libSQL server source id.

Failure messages name both the resolved and expected values, for example:

Conformance suite is not connected to libSQL: expected driver "libSQL JDBC Driver" and database product "SQLite (libSQL)", but resolved driver "SQLite JDBC" and database product "SQLite"

Contract decision

No xerial parity question applies. This is harness integrity, so the guard fails closed: if any driver other than the pinned libSQL driver serves the probe URL, or the server is not libSQL, the suite aborts before the first upstream test. Checks use JDBC-visible behavior (DatabaseMetaData and a SQL query), not harness internals.

Evidence

Failed before the fix (test written first, guard absent):

[ERROR] LibsqlConformanceGuardTest.java:[25,9] cannot find symbol
[ERROR]   symbol:   variable LibsqlConformanceGuard
[ERROR] Failed to execute goal ...maven-compiler-plugin:3.16.0:testCompile

Passed after the fix:

./mvnw -pl libsql-conformance -am verify
Tests run: 106, Failures: 0, Errors: 0, Skipped: 1
BUILD SUCCESS

./mvnw -pl libsql-jdbc -am test
Tests run: 36, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS

./mvnw spotless:apply
BUILD SUCCESS

Fail-fast check: temporarily changing the expected driver name made the same verify fail during launcherSessionOpened, before any test class ran, with the resolved/expected names above. The temporary edit was reverted and the green run above was repeated afterwards.

Deviations

The implementation itself makes no xerial-parity deviation.

Process deviation: this branch is stacked on open PR #28 (feat/jdbc-xerial-conformance) because the conformance harness referenced by #44 does not exist on main yet. The PR diff is limited to the three files owned by this issue; retargeting to main after #28 merges should leave the same three-file diff.

Closes #44