Require deterministic ID ordering for HaveAPI keyset lists

[Kerrycek]

Problem

The new UI has to paginate HaveAPI lists with from_id, which HaveAPI 0.29.8 implements as id > from_id plus LIMIT. The API queries do not provide the matching deterministic order:

• Dataset::Snapshot::Index orders by created_at;
• Dataset::Index orders by full_name;
• SnapshotDownload::Index has no explicit order.

Using the maximum returned ID is the only forward-moving frontend cursor, but it can still skip an unseen lower-ID row when the server page is not ordered by ID. Snapshot replacement makes ID/creation-time divergence a real case. This also affects the Backup Center collectors.

Required upstream contract

This needs a change in the read-only upstream vpsfreecz/vpsadmin API, not a speculative workaround in this repository:

• make every endpoint using from_id order deterministically by its qualified primary key ascending before applying the limit, or expose a cursor that matches the endpoint's declared sort;
• add upstream tests with deliberately non-monotonic creation times/names and more than one page;
• document the ordering guarantee in the API description;
• after the upstream version reaches the test deployment, add a live multi-page regression here and remove the residual-risk note from Make snapshot and download history match the API contract #188.

Current mitigation

#188 corrects the cursor direction, uses a one-row look-ahead for interactive lists, and makes bulk collectors report complete: false when the advertised count exposes missing rows. These measures detect or avoid common failures but cannot establish ordering the server does not guarantee.