Static scenes reject queries at t > 0; every caller rediscovers the workaround

Follow-up to #41. A synthetic scene computes one time point (`[0.0]` by default), and `wp_is_visible` / `get_visibility_to_wp` call `_check_time_in_computed_range`, so the first query at t > 0 raises:

```
ValueError: time=1.0 exceeds the maximum computed time (0.0). Re-run compute_all() with a higher t_max.
```

For a uniform field this rejection protects nothing — the field is identical at every time. Downstream (pyFDS-Evac) the wrapper now clamps every query to the single computed point, but that knowledge belongs in the library: each direct user of the synthetic route will hit the same ValueError and write the same clamp.

Suggestion: when the scene is synthetic (`_uniform_extco is not None`), resolve any query time to the nearest computed point instead of raising — or expose a `static=True` flag on `set_uniform_extco` doing the same. Keep the range check for slice-backed scenes, where extrapolating past the simulation genuinely lies.

Start by tracing wp_is_visible and get_visibility_to_wp into _check_time_in_computed_range, then inspect how set_uniform_extco marks synthetic scenes. Run the existing visibility queries for a synthetic scene at t > 0 and confirm the range check remains unchanged for slice-backed scenes. Done means synthetic queries no longer require caller-side clamping while non-synthetic extrapolation is still rejected.

Written by the indexing model from the issue text.