changes: a footprint answer from graph diff, and its filters applied before table opens #1053

Problem

A client that caches answers per commit needs to know, when a branch moves, which types changed between the commit it shows and the new head. Two routes answer this today, and both cost more than the question needs:

• The change feed returns entity changes with images: 5 commits cost 4.7 s and 469 KB, 20 commits 8.5 s and 540 KB.
• The graph diff on main (feat(changes): graph diff, branch review and merge dry run #966) enumerates rows, and a diff wider than one transaction costs the size of each changed type (performance: graph diff and branch review read both full tables unless the endpoints are one transaction apart #969).

The diff already computes the exact footprint first. changed_table_intervals compares the two manifests by stable table identity and the whole pin (same_state), with no data read. Then plan_intervals:

• opens both endpoints of every changed table (#L392);
• fingerprints their schemas;
• only then applies the kind and type scope (#L415, and in the emit loop).

So a type-filtered diff still opens every changed table twice.

Measured against an OmniGraph 0.13.0 server reached over HTTPS from a laptop (/healthz 0.16–0.21 s on a reused connection), with the release CLI (10 ms start-up), 1–3 runs each. The graph: 101 node types, 552 edge types (149 empty), about 4,900 commits, an Artifact table of about 47k rows. Code references are at main d883c49e.

Proposed change

1. A footprint answer. For example GET /graphs/{id}/diff?from=&to=&view=types, and the same for branch diff. It returns from_commit_id, to_commit_id, and the changed types (kind, name, opaque type id; added, removed or changed), from changed_table_intervals alone, with no table open.
2. Scope before opens. Apply the kind and type filters in plan_intervals before opening tables. Keep the schema-boundary check for in-scope tables, and report schema changes outside the scope in the footprint.

Then diff?from=<commit the client shows>&to=<branch>&view=types names the new head and every type changed since, across branches too, in one request costing about the two manifest reads.

Alternatives considered

• The feed with type filters. It still carries images, and a cursor is bound to its filters (changes: continue change feeds across additive schema changes and outside the request's type filter #1048).
• Comparing published_dataset_version in two /snapshot reads. That version is lineage-local; two branches can share it with different data, as same_state's comment says (api: read answers report the table versions they read and the schema they were answered under #1054).

Related: #969, #970, #1048.