[VibeSWE]

Stacked on #62 (upstream/tool-catalog-1831). Retarget to main after #62 merges.

Problem

resolve_time_range came in with the upstream tool-catalog port (parseablehq#1831). It had four parsing gaps:

1. "now-1h to now" failed with invalid time duration: expected number. The now- prefix branch ran before the to split, and the split was also case-sensitive.
2. "timezone": "utc" was rejected because parse::<Tz>() is case-sensitive. The pre-port code accepted utc case-insensitively, so existing callers silently regressed.
3. today/yesterday returned local day boundary does not exist when local midnight falls in a DST gap (for example, America/Santiago every September).
4. The explicit-range and fallback branches used Utc::now() rather than reference, so resolve_time_range_at wasn't deterministic for them.

Fix

• Split on to (ASCII case-insensitive) first, before any prefix branch.
• Map UTC (any case) to Tz::UTC. Other zones still go through IANA parsing.
• For a missing local midnight, use the first instant after the gap: midnight read with the offset in effect before the transition (first_instant_after_gap).
• Make TimeRange::parse_human_time_at pub(crate) and pass reference to it in both remaining branches. The RFC3339 branch became redundant with the fallback (end = "now" at reference), so it is folded into the fallback.
• docs/tool-api.md now describes the accepted forms accurately.

Tests

New tests in src/tool_executor.rs:

• time_resolution_parses_now_relative_explicit_ranges_against_reference: now-1h to now and now-1h TO now, plus the bare-duration fallback (1h), checked against a fixed 2020 reference.
• time_resolution_accepts_utc_case_insensitively: utc, Utc and UTC.
• time_resolution_starts_days_after_a_dst_gap_at_midnight: America/Santiago, 2026-09-06, for today, yesterday and the preceding day's end.

cargo test --lib time_resolution passes 5/5 locally.

Upstream fidelity

This is a small, local diff in upstream-owned code: one visibility change in src/utils/time.rs, plus branch reordering and one helper in resolve_time_range_at. It is a good candidate to propose upstream. The checked-arithmetic work on the same function (follow-ups 01–13) is separate.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}