fix(sqlite): store datetime binds as ISO-8601 so created_at comparisons work

[sjawhar]

Summary

_convert_arg in the SQLite adapter did not handle datetime, so a datetime bind fell through to stdlib sqlite3, whose legacy adapter serializes with isoformat(" ") (a space separator). The rest of the code stores and compares timestamps as ISO-8601 with a T separator (via parse_db_ts and Python .isoformat()). This patch normalizes datetime binds to .isoformat() in the adapter so stored values match the T form used everywhere else, and backfills existing rows (plus one more write path that needed the same T-form fix) so it doesn't break comparisons against data written before it landed.

Root cause

observability/emitter.py's _write_db inserts conversation_calls.created_at and conversation_events.created_at by binding a raw datetime object (timestamp = datetime.now(UTC)), which stdlib sqlite3's legacy adapter serializes with a space separator (e.g. 2026-07-11 10:00:00+00:00). history/service.py's session-search filters compare created_at against a Python .isoformat() string instead (T separator, e.g. 2026-07-11T10:00:00+00:00):

placeholder = add_param(search.from_time if db_pool.is_postgres else search.from_time.isoformat())
having.append(f"MAX(ce.created_at) >= {placeholder}")

A space (0x20) sorts before T (0x54), so a space-form created_at never compares correctly against a T-form bound value — a session's events can silently fail to match from/to time-range filters regardless of their actual timestamp.

Postgres is unaffected: created_at is a native timestamptz and the bind is a datetime, so the comparison is temporal, not lexical.

Impact (SQLite only)

Any created_at comparison against a Python .isoformat() string, e.g. the session-search from/to time-range filters in history/service.py.

Fix

Normalize datetime binds to .isoformat() in _convert_arg, the single chokepoint every SQLite bind passes through. This generalizes the read-side fix from #430 (which switched to parse_db_ts for the diff viewer) to the write path, so stored timestamps and the values compared against them use the same T form.

Because this changes what a datetime bind produces, existing rows written before this fix (via observability/emitter.py's conversation_calls/conversation_events inserts and observability/session_summary.py's session_summaries.first_seen/last_seen upsert) still carry the legacy space-separated form. Left alone, that produces a new regression: retention/purger.py and retention/archiver.py bind their cutoff as a raw datetime, so once this fix lands the cutoff is T-form while old rows are still space-form — a legacy row from later the same day as the cutoff now wrongly compares as "older" than the cutoff (same lexical ordering bug, in the other direction) and would be purged/archived before its real retention window elapses.

request_logs.started_at/completed_at have the same problem from the other direction: they're written via to_timestamp(?) (a float unix-epoch bind, translated by _translate_params to SQLite's native datetime(?, 'unixepoch')), never a raw datetime bind — so _convert_arg's fix doesn't touch them, and SQLite's own datetime(unixepoch) always emits a space separator, permanently. request_log/service.py's after/before filters, though, bind a raw datetime (datetime.fromisoformat(after)), which after this fix becomes T-form. Without a matching change, a same-day after/before filter would silently return wrong results forever, not just for legacy rows. Fixed by wrapping the to_timestamp(?) → datetime(?, 'unixepoch') translation in replace(..., ' ', 'T').

Migration 024_normalize_legacy_datetime_binds.sql backfills conversation_calls.created_at, conversation_events.created_at, session_summaries.first_seen/last_seen, and request_logs.started_at/completed_at to the T form so old and new rows compare consistently everywhere. The migration only touches SQLite (Postgres never had this bug); the matching Postgres file is a documented no-op kept for the cross-dialect prefix-parity check.

Tests

• TestConvertArg.test_datetime_serialized_as_isoformat_t_separator: _convert_arg(datetime) returns the T form.
• TestSqlitePool.test_datetime_bind_comparable_with_isoformat_string: a strict created_at < own_ts.isoformat() filter excludes the row whose timestamp equals the bound value. Fails before this change, passes after.
• TestTranslateParams.test_to_timestamp: to_timestamp(?) translates to the T-normalizing replace(datetime(?, 'unixepoch'), ' ', 'T'), not bare datetime(?, 'unixepoch').
• TestSqlitePool.test_to_timestamp_write_comparable_with_datetime_bind_filter: a row written via to_timestamp(?) correctly matches same-day >=/< filters bound as a raw datetime. Fails before this change, passes after.
• TestNormalizeLegacyDatetimeBindsMigration.test_legacy_row_wrongly_precedes_new_format_cutoff_until_migrated: a legacy space-form row from later the same day than a T-form cutoff wrongly satisfies created_at < cutoff before the migration runs, and no longer does after. Fails before the migration, passes after.
• TestNormalizeLegacyDatetimeBindsMigration.test_migration_is_idempotent_and_leaves_already_normalized_rows_alone: running the migration twice, and against an already-T-form value, is a no-op.
• TestNormalizeLegacyDatetimeBindsMigration.test_backfills_legacy_request_logs_started_and_completed_at: legacy space-form request_logs.started_at/completed_at values are normalized to the T form.

Verification

• uv run pytest tests/luthien_proxy/unit_tests passes on this branch (full unit suite).
• ruff format --check, ruff check, and pyright are clean on the changed files.

---

The SQLite adapter here is unmodified from upstream aside from this fix. Authored with Claude Code.