feat(memory): add bounded pagination for Memory changes and history

[knqiufan]

Feature description

Add bounded Memory change/history queries for the history portion of D2 in RFC #1455, as a focused deliverable related to #1321.

Problem and proposed solution

At aa697c5315204249e090acdf1a00d0582e851c5f, POST /v1/memory/changes accepts scope_id and since_revision but no page size or cursor. The backend reads Artifact revisions before filtering the requested range and assembling revision changes.

Define a query with deterministic revision/change ordering, a bounded page, and an opaque continuation cursor. A limit on revision count alone is insufficient if a single revision contains many changes.

Acceptance criteria

• Specify page-size bounds, ordering, lower/upper revision boundaries, end-of-list semantics, and cursor validity/expiry.
• Preserve existing documented semantics: since_revision is an exclusive lower bound; 0 requests history from revision 1; a positive nonexistent revision is an error. Explicitly document the existing omitted/null behavior and any versioned migration.
• Define a stable upper boundary or another explicit consistency strategy when new revisions arrive during traversal.
• Bound a page even when one revision has a large change set. Specify continuation within a revision or another explicit bounded representation, preserving precise revision/entry references.
• Do not load all historical revisions and then slice the result. Document and measure remaining per-revision/manifest costs and address anything that violates the declared bound.
• Preserve authorization on every page; reject mismatched, tampered, or expired cursors without leaking another Scope's history.
• Retain change metadata and exact references without expanding all entry bodies; details remain separately retrievable under current authorization.
• Test empty, multi-page, and large-single-revision histories; revision-boundary inputs; invalid cursors; concurrent new revisions; and authorization changes.
• Define an additive/versioned compatibility path. Existing consumers must not silently receive only a first page where they previously received a complete result.
• Update OpenAPI, generate derived code with make api-generate, and run make contract-test, focused behavior tests, and required checks.

Alternatives considered

• Loading complete history and paginating in Desktop: unbounded Server and network cost.
• Limiting revision count alone: does not bound a large change set inside one revision.
• Using Candidate history as Memory history: different authoritative data and semantics.

Additional context

• Refs bug: Memory append storage and latency grow superlinearly with entry history #1321, docs(rfc): propose Tauri desktop control center #1455 (D2), and Tracking Issue: deliver a secure PowerContext desktop control center #1428.
• Current request/response contract.
• Current revision loading and filtering.
• Open for community implementation in a focused PR targeting master. Coordinate cursor/compatibility choices with the entries-pagination issue, while keeping each deliverable independently reviewable.
• This gates the Memory history UI, not the initial Desktop connection/save/search workflow. It does not introduce retention, erasure, compaction, or a general audit/event stream.

Desktop consumer: #1654.
Related entry-pagination deliverable: #1656.

[wutongyuonce]

The coordinated contract and persistence boundary are documented in #1656:

#1656 (comment)

For #1657, I will reuse the accepted shared seam rather than request a second set of decisions:

• additive paged operation preserving current complete-history behavior;
• the existing signed, endpoint/Scope/query-bound cursor and authorization on every page;
• a pinned upper Memory revision;
• (revision ASC, change_ordinal ASC) ordering;
• continuation within a revision, with limits counting changes;
• normalized change rows so a large revision is not fully loaded for one page;
• exact change metadata/references without entry-body expansion;
• the same explicit offline plan/apply/verify backfill pattern for existing SQLite and OceanBase data.

This remains a separate PR after #1656 establishes the shared contract. Retention, compaction, erasure, and the broader #1718 capacity contract remain out of scope.

No separate #1657 design decision is requested. Any necessary coordination should be resolved once on the linked #1656 boundary.