Fix SQLite URI file databases losing schema across DBI connections

[fglock]

Summary

PerlOnJava does not persist schema changes across separate DBI connections to the same SQLite URI-backed file database. A table created and committed through one connection is absent when the same URI is opened by a second connection.

CPAN impact

TheSchwartz::JobScheduler 0.002 failed in CPAN tester run 20260827-171022-1876. Its database setup creates the TheSchwartz SQLite schema, including funcmap, then the scheduler obtains another handle through its dbh_callback. The scheduler fails immediately at SELECT funcid, funcname FROM funcmap with no such table: funcmap.

Affected upstream tests are t/insert_job.t, t/insert_job_uniqkey.t, t/use_adhoc_dbhandle.t, and t/use_database_managedhandle.t. The target report has 4 of 7 test programs failing and 5 of 10 subtests failing.

System Perl baseline

With the target test prerequisites installed into an isolated library, system Perl passes the unchanged upstream suite completely:

Files=7, Tests=10
Result: PASS

Focused reproducer

1. Connect with DBI to dbi:SQLite:uri=file:?mode=rwc.
2. Execute CREATE TABLE funcmap (funcid INTEGER PRIMARY KEY, funcname TEXT), then disconnect.
3. Reconnect with the identical DSN and run SELECT count(*) FROM funcmap.

System Perl with DBD::SQLite returns 0. Both PerlOnJava JVM and interpreter backends fail at prepare with no such table: funcmap.

The SQLite URI is file-backed rather than an in-memory DSN, so separate connections must observe committed schema changes.

Acceptance criteria

• Add a project-owned, system-Perl-validated regression that creates a schema through one URI-file SQLite handle and queries it through a second handle.
• Both PerlOnJava backends observe the table and return the expected row count.
• Preserve existing SQLite connection isolation semantics for genuinely distinct DSNs.
• TheSchwartz::JobScheduler 0.002 database tests pass with the maintained dependency overlay.

[fglock]

Resolved by merged PR #1188.