temporal-querylisted

# Temporal Query Point-in-time and version-chain lookups over the bitemporal columns (`valid_from`, `valid_to`, `superseded_by`) that `mem_003_temporal` added to `memories`. Ordinary search cannot answer these questions: `search`, `list`, `stats` and single-id lookups all filter `valid_to IS NULL`, so they only ever see the current state. ## What the temporal columns actually mean Read this before phrasing an answer — getting the axis wrong produces confident but false claims. - `valid_from` / `valid_to` track **when the store recorded a version**, not when the fact was true in the outside world. `as_of=T` answers *"what did this memory store hold at T"*, not *"what was true at T"*. If the user recorded a 2024 decision yesterday, it enters the timeline yesterday. - `update` does **not** edit in place. It closes the old row (`valid_to = <update time>`, `superseded_by = <new id>`) and inserts a new row with a **new id** and `valid_from = <update time>`. The id in the user's notes from last month no longer resolves through `search`. - `delete` also closes the row (`valid_to` set) but leaves `superseded_by = NULL`. That is the discriminator: a closed row with a forward pointer was **replaced**; without one it was **retracted**. - Rows created by `add` / `capture` carry `valid_from = NULL`; queries fall back to `created_at` via `COALESCE`. A `null` `valid_from` in a result means "original version", not a data defect. - `commit_sha` is present in the schem