[ako]

Syncs ako/mxcli:main into upstream: 1 commit from fork PR ako#1802.

Refs #1081 and #1329.

Incremental source-catalog rebuilds

Problem: once a project had a source index (refresh catalog full source), every later rebuild described every document again. That included the implicit rebuilds that search and show references start after every save. On a 4,753-unit app that took 38 s each time.

This follows from #1081's never-narrow guard: the cheapest rebuild that can still be saved is the most expensive one.

Fix: a source build now records what it described from:

• source_units: every unit's content hash and container;
• source_elements: which document came from which unit;
• a fingerprint of the mxcli build that wrote the rows.

The next build carries a document's row over only when all of these hold:

1. Its own unit is unchanged. An entity's unit is its domain model, and the container is compared too, because a move into another folder changes the described folder.
2. No document its references name has changed. For example, a page prints its data-source flow's return entity.
3. Nothing changed outside the described documents. A folder, module, settings or Java action change describes everything, as before.
4. The same mxcli build wrote the rows.

FORCE still describes everything. Anything the plan can't vouch for is described again, so reuse can make a build faster but can't change its result.

Other details:

• Reader.UnitContentHashes reads v2 hashes from the Unit table, and computes v1 hashes from the blob, because older v1 writes left them stale.
• No schema bump is needed: a cache without the new tables simply reuses nothing.

Evidence

• TestSourceCatalog_IncrementalBuildEqualsFullBuild compares the incremental build with a forced full build, row for row, after each of these:
  • no change;
  • a flow edit;
  • a callee's return type changed;
  • a data-source flow returning another entity;
  • a flow added, renamed or dropped;
  • an entity altered;
  • a flow moved to a new folder, and another moved into it.
• Controls:
  • With dependency tracking stubbed out, the test fails on the page whose data-source flow changed.
  • Without the container in the comparison, it fails on the folder move.
  • It fails if no build reused rows.
• On a 4,753-unit MPR v2 app, after alter entity … add attribute, a plain refresh catalog takes 11.2 s instead of 38.2 s, reusing 3,525 of 3,718 rows. The result is byte-identical to a forced full rebuild.
• Docs: the Caching section of docs-site/src/tools/refresh-catalog.md explains the incremental rebuild and what FORCE does