fix(query): render named-timezone timestamps

[anoop-narang]

Summary

A timestamp column whose type carries a named IANA timezone (UTC, America/New_York) renders as null when a result is fetched, instead of showing its value. Fixed-offset (+00:00) and zone-less timestamps were unaffected, so a neighbouring column in the same row looked fine.

The data was never wrong — only the rendering.

Cause

Results are fetched as Arrow IPC and formatted client-side, so a timestamp arrives as a raw integer plus a timezone recorded in the Arrow schema. Turning that into text for a named zone requires a timezone database. arrow was declared with default-features = false, so none was compiled in and ArrayFormatter::try_new returned an error for those values:

ArrayFormatter::try_new(col, &opts)
    .map(|f| Value::String(f.value(row).to_string()))
    .unwrap_or(Value::Null)          // error became a null cell

A fixed offset parses arithmetically and a zone-less timestamp needs no lookup, which is why only named zones broke.

Regressed in 50e3439, which moved result fetching from JSON to Arrow — before that the service formatted every value and sent strings, so the client never had to resolve a timezone.

Fix

1. Enable arrow's chrono-tz feature so named zones resolve.
2. Stop converting a formatting failure into null. The cell is already checked for null above that arm, so reaching it means a present value could not be rendered — reporting null asserts the opposite and is indistinguishable from a real null to anything reading the output. The shape is kept (callers rely on one value per column) and the failure now goes to stderr, deduplicated once per run so a large result cannot flood the terminal.

Verification

Against the live API, fetching the same stored result with the released build and this one:

columns:      ts_utc                ts_ny                       ts_naive             n

0.29.0        NULL                  NULL                        2026-01-01T12:00:00  7
this branch   2026-01-01T12:00:00Z  2026-01-01T12:00:00-05:00   2026-01-01T12:00:00  7
served inline 2026-01-01T12:00:00Z  2026-01-01T12:00:00-05:00   2026-01-01T12:00:00  7

The client now matches what the service returns when it formats the same query inline.

Tests

• named_timezone_timestamps_render_instead_of_nulling — named zones across several time units, plus the fixed-offset and zone-less forms kept as controls so a regression narrows to the named-zone case, and a genuine null still rendering as null.
• no_column_type_silently_renders_as_null — sweeps the temporal and decimal types a query can return (Date32/64, Time32/64, Duration, Decimal128, all four Timestamp units in naive, UTC, fixed-offset and named-zone forms) and asserts none renders a present value as null. This guards the wider hazard rather than just this instance: every type without an explicit arm falls through to the same formatter.

Both fail without the feature (Timestamp(s, UTC) has a value at row 0 but rendered as null) and pass with it. cargo fmt, cargo clippy --all-targets -- -D warnings and the full suite pass.

[claude]

Fix and tests match the described cause. Two non-blocking nits inline. CI / test was still pending at review time, so the new tests are unverified here.

[codecov]

Codecov Report

❌ Patch coverage is 96.52174% with 4 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/commands/query.rs	96.52%	4 Missing ⚠️

📢 Thoughts on this report? Let us know!

[claude]

Both prior nits are addressed: the warning is now keyed per data type, and the per-value path uses try_to_string instead of Display. No further findings.

Note: CI / test and CI / fmt were still pending at review time, so the new try_to_string call is not confirmed to compile from this review.