Decide SQL temporal aggregate reduction semantics

[milindsrivastava1997]

What to decide

Decide whether SQL's explicit temporal functions, asap_rate and asap_increase, should lower to Reduction::PerEntity or to a Reduction::Reduce(...) form.

Ordinary SQL aggregates are cross-entity Reduce operations. The current temporal bridge is the exception: it lowers to TimeRange + PerEntity, matching PromQL's per-series range semantics. This choice affects output identity, timestamp retention, schema shape, summary realization, and what SQL's GROUP BY means around a temporal function.

Current behavior

asap_rate(value, ts, window)
  → TimeRange
  → Aggregate { reduction: PerEntity, measures: [Rate] }

The implementation work for #409 will proceed with this existing behavior and expose the derived measure as rate / increase internally. This issue must determine whether that is the intended long-term SQL semantic contract.

Acceptance criteria

• Record the intended SQL semantics for asap_rate and asap_increase, including entity identity, time-axis behavior, and interaction with GROUP BY.
• Choose PerEntity or Reduce and explain why the alternative is incorrect or deferred.
• Specify the required output-schema and SQL alias behavior.
• Identify any migration or compatibility consequences for existing temporal SQL queries.

Blocked by

None — decision can proceed in parallel with #409, whose current implementation follows the existing PerEntity behavior.