config: sanitize_iso_date should accept full ISO-8601 with time component

[igorls]

Background

#1167 added `sanitize_iso_date()` to `config.py` and wired it into `tool_kg_query` (`as_of`), `tool_kg_add` (`valid_from`), and `tool_kg_invalidate` (`ended`). The validator currently accepts `YYYY`, `YYYY-MM`, `YYYY-MM-DD`, and passes through `None`/`""`.

Gap

The PR title says "validate ISO-8601 date formats" but the regex rejects:

• `YYYY-MM-DDTHH:MM:SS` (full ISO-8601 datetime)
• `YYYY-MM-DD HH:MM:SS` (SQLite TEXT-with-space datetime, which SQLite happily orders correctly)
• Trailing `Z` or `±HH:MM` timezone offsets

This is acceptable for v3.3.5 (the existing kg path stores dates, not datetimes, and lex-ordering of `YYYY-MM-DD` matches calendar order). But it's an unnecessarily narrow contract for callers that legitimately have a sub-day timestamp — a chat record with `occurred_at="2026-05-06T14:23:00Z"` cannot pass it through.

Proposal

Expand `sanitize_iso_date` to also accept:

• `YYYY-MM-DDTHH:MM:SS`
• `YYYY-MM-DDTHH:MM:SS.fff` (millisecond precision)
• `...Z` and `...±HH:MM` timezone suffixes
• `YYYY-MM-DD HH:MM:SS` (SQLite-flavored space separator) — consider whether to accept-and-normalize-to-T or reject

Lex order of `YYYY-MM-DDTHH:MM:SS` still matches calendar order, so the KG TEXT-comparison invariant holds.

Open questions

• Rename the function? `sanitize_iso_date` is misleading once datetimes are accepted. Consider `sanitize_iso_temporal` or `sanitize_iso_8601`.
• Backward-compat: existing callers that synthesize dates would still pass; this is a strict superset of accepted forms.

Surfaced during review of #1167. Tracked separately because the v3.3.5 fix already unblocks the silent-empty-result foot-gun.