Fix AI-reported bugs against current main type rules

[mattcasters]

Verified against current main / 2.20 type rules, not 2.19 getFieldDefinition. That is the answer to the review notes on #8220 / #8221.

Already handled by #8214 (Database perspective)

These are not in this PR. Comments are on the issues; they should close when #8214 merges:

• [Bug]: The query timeout is not applied to DDL/DML statements #8224 query timeout on DDL/DML
• [Bug]: Database cancel-watcher threads never terminate in Hop Web — two of them are non-daemon #8228 cancel-watcher leak in Hop Web
• [Bug]: SQL editor fetches the whole result set — its 1000-row limit is applied client-side only #8229 SQL editor 1000-row cap is client-side only

#8217 was already closed (UNIQUEIDENTIFIER on both SQL Server dialects).

This PR

Issue	Change
#8216	Hop Number length is JDBC precision (total digits). numericLength() stays integer digits for dialect rule conditions. PostgreSQL writes NUMERIC(length, scale) so it round-trips. Does not merge #8242 as-is (that inverts numericLength() and would inflate Postgres precision).
#8218	Timestamp parse mask reads HOP_DEFAULT_TIMESTAMP_FORMAT
#8219	Stream Lookup Timestamp default no longer throws ConversionNotImplemented
#8220	SQL Server DATE / TIME / DATETIME2 via type rules; new Date fields stay DATETIME
#8221	SQL Server NVARCHAR/NCHAR preserved; TEXT replaced with VARCHAR(MAX)
#8222	Parameter metadata goes through StandardJdbcTypeMapper (NVARCHAR, NUMERIC(p,s))
#8223	Ordinary JDBC no longer calls the data-service getColumns() path
#8225	Empty leftover metadata folders are not listed under Unknown
#8226	catalog.schema is split even when supportsCatalogs() is false
#8227	ProgressMonitorDialog disposes when the runnable returns (Get fields no longer hangs)
#8230	Dead View-menu terminal constants and unused USE_ADVANCED_TERMINAL key removed

Tests

Focused modules run under tools/with-isolated-display.sh: core, ui, mssql, mssqlnative, postgresql (+ redshift/greenplum/cockroach), mysql, oracle, streamlookup.

Fixes #8216 #8218 #8219 #8220 #8221 #8222 #8223 #8225 #8226 #8227 #8230

[fskorgen]

Thanks for taking these on!

We run 2.19 in production and have local patches for a few of them, so we are not
blocked. But #8216 is the one that hurts: the shortened DECIMAL length breaks our
job runs. That fix looks self-contained in StandardJdbcTypeMapper, which is in 2.19
too, unlike the SQL Server ones that need the 2.20 type rules.

We have patched #8220/#8221 ourselves, but anyone else on 2.19 with SQL Server will
get wrong DDL for Unicode columns.

Is a 2.19 patch release planned, and could #8216 go into the 2.19 branch?

[mattcasters]

Thanks for filing the issues @fskorgen. If you're not blocked my idea is that it's best for give this PR some mileage until the 2.20.0 release in October. 2.19.0 should have a compatibility flag for the DDL issues as well so not so blocking for others either I think.
The flag is gone in main (2.20.0) since the backend got reworked with even more flexibility. That's what the comments from @hansva were about.
If you find the time, do try out this PR and let us know if there's anything missing for your deployment.

[bamaer]

Nice cleanup overall — the timestamp mask fix, the TYPE_TIMESTAMP case in StreamLookup, the try-with-resources on getColumns(), and routing ordinary JDBC away from the SOURCE_DATA_TYPE switch all look right, and the totalDigits() split does what it claims (characterization goldens drop 62 → 15 divergences).

One blocker before this can go in:

Error dialog is swallowed on "Get Fields" — GetQueryFieldsProgressDialog.java:75 + ProgressMonitorDialog.java:194

The new monitor.done() in the runnable's own finally disposes the progress shell while the InvocationTargetException is still propagating — before runMonitoredWork reaches its catch and assigns targetException. pumpDisplayUntilShellDisposed() only checks the exception fields at the top of the loop, so it exits on shell.isDisposed() and returns normally: showErrorDialog() never fires and open() returns null. A bad query in Table Input's Get Fields now fails silently.

Suggested fix: re-check interruptedException/targetException after the loop, and drop the added monitor.done() — the new finally { dispose(); } in ProgressMonitorDialog already covers the hang it was guarding against.

Two more I'd fix here since they're small:

• PostgreSqlDatabaseMeta.java:480 — the switch to NUMERIC(length, precision) is the right call (the old length+precision inflated scale on every round trip), but length >= precision isn't guaranteed the way length+precision >= precision was, so scale > precision can emit DDL that PostgreSQL < 15 rejects. The new test asserts NUMERIC(5, 7), which is exactly that case. Worth a clamp plus a test change. The narrowing of hand-authored Number(10,3) → NUMERIC(10,3) is correct per Hop semantics but changes generated DDL for existing users — worth a release note.
• Database.java:2295 — getQueryFieldsFallback is called inside the try and again in the catch, so a failing fallback runs the user's SQL twice.

Non-blocking, happy to see these as follow-ups:

• MsSqlServerDatabaseMeta.java:81 — originalColumnType is checked before the Hop type, so a DATE column explicitly converted to Timestamp still generates DATE and loses the time. Swapping the two checks would fix it.
• Database.java:3485 — the explicit Types.NUMERIC → ValueMetaInteger mapping is gone; drivers reporting precision 0 now yield a double-backed ValueMetaNumber.
• DatabaseMeta.java:1098 — dropping the supportsCatalogs() guard changes behavior for the four dialects that return false (MSSQL, Access, Gupta, Iris). I think it's a net improvement (mydb.dbo used to quote as the broken [mydb.dbo]), but it does mean a schema with a literal dot now splits. Just confirming that's intentional.

[mattcasters]

Thanks @bamaer — addressed in c9336ec:

Blocker (Get Fields error dialog)
Dropped the extra monitor.done() in GetQueryFieldsProgressDialog. ProgressMonitorDialog still disposes in runMonitoredWork's finally, and pumpDisplayUntilShellDisposed now re-checks targetException / interruptedException after the loop so a failed Get Fields still surfaces the error dialog.

PostgreSQL NUMERIC
NUMERIC(p, s) now uses p = max(length, scale) so PostgreSQL < 15 does not reject scale > precision. The Number(5,7) test expects NUMERIC(7, 7). The 2.20 meaning (NUMERIC(length, scale) rather than length+precision) is noted on the PostgreSQL connection page and in the column-types dev doc.

getQueryFieldsFallback
Fallback is only used to recover from the prepared-statement / data-service paths. The ordinary JDBC branch already ran it; a second call would execute the SQL twice.

Follow-ups included

• SQL Server: Hop TYPE_TIMESTAMP is checked before original Types.DATE, so a DATE column converted to Timestamp generates DATETIME2.
• Parameter metadata: unsized NUMERIC/DECIMAL (precision 0, scale 0) maps back to Integer.
• quoteSchema: splitting catalog.schema without the supportsCatalogs() gate is intentional (comment in DatabaseMeta). A schema whose name contains a literal dot is the rare case; mydb.dbo as one identifier was the bug.

[fskorgen]

I tested this against live databases, since #8216 is mine and these dialects
are not covered by CI.

The column is identical on every database, DECIMAL(18,6) holding
123456789012.123456, created with plain SQL. All of them store it exactly,
so the only variable is Hop. Measured on main at 9925b3f, with and
without this PR.

Before, on current main — all four wrong:

Database	Column	Hop reads as	Value	getFieldDefinition writes
MSSQL	decimal(18,6)	Number(12,6)	rounded	DECIMAL(12,6)
MonetDB	decimal(18,6)	Number(12,6)	rounded	DOUBLE
PostgreSQL	numeric(18,6)	Number(12,6)	rounded	NUMERIC(18,6)
Infobright	DECIMAL(18,6)	Number(12,6)	rounded	DOUBLE

Two separate consequences. The value loses digits everywhere. And on MSSQL a
Table Input to Table Output copy produces a target column four digits too
narrow for the data the source held; MonetDB and Infobright lose the exact
type entirely. PostgreSQL keeps its shape only because its writer adds the
scale back, 12 + 6 = 18, cancelling the subtraction.

After, with this PR — all four correct:

Database	Hop reads as	Value	writes
MSSQL	BigNumber(18,6)	exact	DECIMAL(18,6)
MonetDB	BigNumber(18,6)	exact	DECIMAL(18,6)
PostgreSQL	BigNumber(18,6)	exact	NUMERIC(18,6)
Infobright	BigNumber(18,6)	exact	DECIMAL(18,6)

Nothing left over that I can see: value, derived type and round-tripped
column are all right on every dialect I have.

Also ran core plus the six modules this PR touches, 1301 tests, with and
without it. Four classes fail either way (config serialization, OIDC, VFS
network providers, JDBC characterization), so none is caused by this PR.

Scope: I only tested type mapping, and only these dialects. Infobright is
not a Hop dialect, so it was read through MARIADB.