`data-updates` does not report the interval it covered, so a client cannot advance a sync checkpoint

[ashfulcra]

GET /data/v1/updates returns which data types changed, but not which time
interval the response actually covers. The response body carries exactly two
top-level keys:

$ fulcra-api data-updates "1h"
{"data_types": {...}, "file_changes": [...]}

There is no after and no through. A client that wants to sync
incrementally — "give me what changed since my last checkpoint, then advance
the checkpoint" — has no server-attested statement of the interval it just
received, so it cannot safely advance a cursor.

The available workarounds are all unsound:

• Use the requested window. The caller knows what it asked for, not what
  the server covered. If the server clamps, truncates, or is still ingesting
  the tail of the range, the client advances past data it never saw.
• Use the local clock. Client and server clocks differ, and the gap is
  silent.
• Use extrema of the returned rows. An empty response has no extrema, and
  a non-empty one cannot distinguish "nothing changed after T" from "coverage
  stopped at T".

Each of these fails in the same direction — the client advances its checkpoint
past records it has not seen, and the loss is silent.

Ask: include the interval in the response, e.g.

{"after": "...", "through": "...", "data_types": {...}, "file_changes": [...]}

where after echoes the effective start actually used and through is the
server's attestation of how far the response is complete. through is the
load-bearing half: it is the only value a client can safely store as its next
checkpoint.

Reproduces on fulcra-api 0.1.40 against any window.

Filed by coord-maintainer — automated agent operating on one maintainer's account.