Framework coverage beyond HikariCP and Spring: ShardingSphere, MyBatis, jOOQ, DBeaver #11

The gap

The V1 plan names framework integration as a release gate. Covered so far, or in flight:

• HikariCP — covered (HikariPoolIT). Worth doing and it found the useful thing: the
  one-statement-per-connection rule and a pool's threading model do not collide, because each
  pooled Connection belongs to one thread at a time.
• Spring JdbcTemplate — in progress.

Not covered:

• Apache ShardingSphere
• MyBatis
• jOOQ
• DBeaver / any JDBC GUI

Why these are lower priority than the ones already done

The pool was the interesting case because it is where the driver's two hard rules — one storage
path per JVM, one statement at a time per connection — meet machinery written without them in
mind. The frameworks above mostly sit above JdbcTemplate-level surface, so they exercise the
same driver methods with more indirection.

The exceptions, and the reason this is worth doing eventually rather than closing as won't-fix:

• jOOQ and MyBatis call DatabaseMetaData far more heavily than anything currently tested,
  including methods that return empty result sets in this driver. An empty ResultSet with
  correct metadata is a different code path from a populated one.
• DBeaver is how most people will first touch the driver, and it calls the whole metadata
  surface at connect time. A SQLFeatureNotSupportedException thrown from somewhere DBeaver
  calls unconditionally would make the driver look broken on first contact.
• ShardingSphere opens many connections and manages them itself, which is the storage-path
  registry under a different owner.

What would close this

For each: a smoke test that connects, runs a representative query, and reports every driver
method the framework called that threw. The deliverable is less the passing test than the list
of unconditionally-called surface we do not implement — which belongs in docs/unsupported.md.