Naive datetime values are interpreted in the host's local time zone

## Behaviour

Converting a Python value to a CEL `timestamp` (in `RustyPyType::try_into_value`) handles a timezone-aware `datetime` correctly, but a naive one is passed through `chrono::Local`, so the same `datetime(2026, 1, 1, 12)` is a different instant on a `UTC` server and on a developer's laptop. CEL timestamps are absolute instants, and every `timestamp(...)` literal an expression builds is UTC, so comparisons like `created > timestamp("2026-01-01T00:00:00Z")` silently depend on `TZ`.

`datetime.now()` (naive) is the common way to hit this. The quick-start guide, the tutorials and the `Context.add_variable` docstring all use naive `datetime.now()` as the example value, so the docs currently teach the footgun.

## Options

1. **Keep local, document loudly.** Matches Python's own convention (`naive.timestamp()` assumes local time). Least disruptive; add a warning box to the Python API reference and the datetime section of the tutorial, and switch the doc examples to `datetime.now(timezone.utc)`.
2. **Treat naive as UTC.** Deterministic across machines and matches what most server code means. Silent behaviour change for anyone relying on option 1.
3. **Reject naive datetimes** with a `ValueError` that says to attach a `tzinfo`. Loudest and safest; a breaking change for existing callers.

My lean is 1 now (with the doc examples fixed) and 3 at the 1.0 boundary, since a policy engine that gives different answers per host TZ is the kind of bug that only shows up in production. Opinions welcome before anything changes.

從 RustyPyType::try_into_value 開始，檢查 datetime 轉換，接著檢閱 Python API 參考、快速入門指南、教學課程，以及 Context.add_variable docstring 中的範例。將提出的三種 naive datetime 策略與現有行為和專案方向進行比較。策略達成共識、在需要時完成實作，且所有受影響的文件範例都一致地反映該策略，即視為完成。

由索引模型根據 Issue 內容生成。