sub-second duration truncated to 0ms in SQL start_timestamp calc #510

Where

asap-query-engine/src/engines/simple_engine/sql.rs, build_spatiotemporal_context (currently around line 736-737):

let duration_secs = match_result.outer_data()?.time_info.get_duration() as u64;
let start_timestamp = end_timestamp - (duration_secs * 1000);

TimeInfo::get_duration() returns f64 seconds. Casting straight to u64 before multiplying by 1000 truncates any sub-second component — e.g. a genuine 0.3s duration becomes 0u64, so the computed offset is 0ms instead of 300ms.

Found while fixing the same shape of bug in build_query_requirements_sql's data_range_ms computation as part of #500 (Phase A1). This one is the same class of bug but predates that diff, so it's out of scope for #500's minimal, behavior-preserving steps and is being filed separately instead.

The identical pattern also exists (twice) in calculate_start_timestamp_sql, but that function is dead code scheduled for deletion in #500's Phase A2 (SQL dispatcher unification), so it goes away on its own there.

Reachability

Whether this is reachable in practice depends on whether any SQL query can produce a fractional-second duration (e.g. one bound resolved via bare NOW() and the other via an absolute literal, if the runtime query_time passed to the engine isn't second-aligned) and whether data_ingestion_interval_ms is ever sub-second in deployment. Not yet confirmed either way.