Updated DuckDB to version: v1.5.3

Fixed Server can now start in read-only mode (--readonly / -O). Previously, startup failed with Catalog Error: Cannot launch in-memory database in read-only mode! because the system-catalog ATTACH ':memory:' AS _gizmosql_system inherited the parent database's READ_ONLY access mode. Both the system-catalog attach and the (Enterprise) instrumentation database attach now specify (READ_WRITE) explicitly, so server-managed metadata and instrumentation continue to work even when the user's main database is opened read-only. Added tests/integration/test_read_only_mode.cpp as a regression guard.

GetTables schema now carries real per-column metadata. The Arrow schema returned via Flight SQL GetTables with include_schema=true previously came straight from SELECT * FROM t LIMIT 0, which marks every field nullable and carries no DDL metadata. DuckDBTablesWithSchemaBatchReader now also queries duckdb_columns() per table (with proper ? parameter binding) and applies: Field.nullable ← real NOT NULL constraint (fixes DBeaver's column-browser Nullable checkbox). Metadata ARROW:FLIGHT:SQL:REMARKS ← column comment (populates JDBC REMARKS). Metadata ARROW:FLIGHT:SQL:IS_AUTO_INCREMENT ← "1" when the default starts with nextval(, else "0" (populates JDBC IS_AUTOINCREMENT). Metadata GIZMOSQL:COLUMN_DEFAULT ← the column's default expression, exposed through the GizmoSQL JDBC driver v1.6.1+ as JDBC COLUMN_DEF. Fully backward-compatible: all three metadata keys are ignored by old clients; the standard Flight SQL JDBC driver picks up REMARKS + IS_AUTO_INCREMENT for free (they are upstream Apache Arrow Flight SQL spec keys). _gizmosql_system system catalog (DuckDB backend). Server init SQL now ATTACH ':memory:' AS _gizmosql_system and creates two JDBC-shaped metadata helper views inside it, so Flight SQL clients can recover metadata that the Flight SQL protocol itself does not expose: Fixed DECIMAL prepared-statement parameter binding aborts the server process. Prior to v1.22.0, executing a prepared INSERT / UPDATE bound to a DuckDB DECIMAL column could trigger Arrow's ValidateDecimalPrecision check and SIGABRT the gizmosql_server process (exit 134). Surface symptom on the client was a raw UNAVAILABLE: Network closed for unknown reason / gRPC channel termination — the server process just disappeared mid-query. Three distinct bugs in duckdb_statement.cpp::GetDataTypeFromDuckDbType were fixed together: the DECIMAL arm never populated width/scale from the DuckDB type (hardcoded 0), the arrow::smallest_decimal(...) call had its arguments flipped ((scale, width) instead of (width, scale)), and returning a Decimal32/Decimal64 type is not accepted by the Arrow Java JDBC client (which only supports Decimal128 / Decimal256). The server now emits Decimal128(width, scale) for precisions 1–38, Decimal256(width, scale) for precision > 38, and falls back to Decimal256(38, scale) when DuckDB reports width == 0 (unresolved parameter placeholders in statements like INSERT INTO t(decimal_col) VALUES (?)). Regression coverage lives in the GizmoSQL JDBC driver repo's GizmoSqlIntegrationIT.testDecimalParameterRoundTrip, exercised against gizmodata/gizmosql:latest on every JDBC CI run. Bulk ingest with temporary=True (issue #158): Repeated adbc_ingest(..., temporary=True) calls (or any Flight SQL CommandStatementIngest with temporary=true) no longer fail with Catalog Error: Table with name "..." already exists! (for create_append/replace) or Table: "..." does not exist (for create then append). The server's table-existence check previously only consulted the current database catalog, so temporary tables — which DuckDB stores in the implicit temp.main catalog — were invisible to the lookup. TableExists() now scopes to temp.main when the ingest is temporary. Thanks again to @fromm1990 for the report and reproducer.

* Upgraded DuckDB to v1.5.2 - and DuckLake to v1.0 * Now auto-restart server on foregrounding and notify user of disconnected clients on backgrounding the app.