Type/semantics: CEL timestamp operations (tz-aware accessors, overflow rules)

[rrrodzilla]

Workstream: Type system · Part of #89

Context

We already have DateTime<Utc>. CEL adds rich timestamp operations: tz-aware accessors (getDayOfWeek, getHours(tz), getFullYear), timestamp/duration arithmetic, and defined overflow semantics (we already hand-cite the spec in cel objects.rs / our own time handling).

Scope

• Expose CEL timestamp operations over our DateTime in rules.
• Commit to CEL's tz/overflow semantics; document them.

Acceptance

• Rules can use tz-aware accessors and timestamp/duration arithmetic with spec-conformant overflow behavior.

Pairs with the duration type (sibling type issue).

---

Dependencies: Lands with the evaluator (#91); pairs with the duration type #96. Soft.

[rrrodzilla]

Verified already-complete — overflow guarantee locked in by c1a9616 (test(cel): lock in timestamp/duration overflow rules).

Investigation confirmed CEL timestamp/duration arithmetic already range-checks in eval/ops.rs (ts_plus_duration, duration_plus_duration, in_range_duration use checked math + ts_in_range / int64-nanosecond bounds and return "range error" — no wrap, no panic), complementing the conversion-side bounds in convert.rs (TS_MIN_SECS, ts_in_range, duration_in_range) and the tz-aware accessors in time.rs (#109). All 7 overflow-boundary expressions return range error; locked in with 3 explicit boundary tests (timestamp_add_duration_overflow_is_range_error, timestamp_minus_timestamp_overflow_is_range_error, duration_add_duration_overflow_is_range_error). No code fix was needed. timestamps conformance 73/76 (remaining are proto/typed-result shapes, not overflow).