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.

Start at RustyPyType::try_into_value and inspect the datetime conversion, then review the Python API reference, quick-start guide, tutorials, and Context.add_variable docstring examples. Compare the three proposed naive-datetime policies with existing behavior and project direction. Done means the policy is agreed, implemented if required, and all affected documentation examples consistently reflect it.

由索引模型根据 Issue 内容生成。