Fix typmod defaulting to 0 instead of -1 for all types

[fuziontech]

Summary

• Fix typmod=-1 default: All TypeInfo returns that didn't explicitly set Typmod were getting Go's zero value (0) instead of PostgreSQL's "no modifier" sentinel (-1). This caused JDBC clients (pgjdbc) to misinterpret column metadata — most critically for INTERVAL, where typmod=0 means "second precision 0" (no fractional seconds) vs typmod=-1 meaning "default precision" (microseconds).
• Add missing rows.Err() check in handleExecute: The extended query protocol's Execute path didn't check for streaming errors after the row iteration loop. The simple query path (executeSelectQuery) already had this check. Without it, gRPC stream errors from workers could be silently swallowed, sending CommandComplete to the client without reporting the error.

Context

Metabase (JDBC/c3p0) was reporting java.util.NoSuchElementException when running select worker_version(), uptime() with no corresponding errors in duckgres logs. The uptime() macro returns an INTERVAL. pgjdbc's TypeInfoCache.getScale() returns typmod & 0xFFFF when typmod != -1, so typmod=0 → scale=0 (no fractional seconds), while typmod=-1 → scale=6 (default microsecond precision). This metadata mismatch between what duckgres reports and what the actual data contains is the likely root cause of the JDBC client error.

Test plan

• New TestMapDuckDBTypeTypmod verifies all types return typmod=-1 except HUGEINT, UBIGINT, and DECIMAL(p,s) which have specific positive typmods
• Existing TestMapDuckDBType still passes (OID/Size unchanged)
• Full go test ./server/ passes
• go build ./... succeeds

🤖 Generated with Claude Code