fix(record): prefer branch-qualified cells over legacy cells

[abn]

build-site now indexes the branch-qualified cell when a records dir holds both a legacy <app-id>-<arch> cell and a fresh <app-id>-<branch>-<arch> cell for the same app, architecture, and branch. An in-place upgrade can no longer publish a stale digest and labels.

Problem

A records dir that survives an upgrade can hold two cells for one app, architecture, and branch: the legacy <app-id>-<arch> cell and the branch-qualified <app-id>-<branch>-<arch> cell that #162 introduced. IterRecords sorts cells by directory name, so the legacy cell is returned last, and mergeRecord keeps the last write for a given ref and architecture. The stale legacy digest and labels win, silently.

Fix

IterRecords now prefers the branch-qualified cell. When both forms exist for the same app, architecture, and branch, the legacy cell is dropped, deterministically and independent of write order. A legacy cell with no branch-qualified counterpart still loads, so records that have not been re-pushed keep working.

Coverage

• Unit tests pin the preference in both lexical orders (the legacy cell sorts before its replacement for some architectures and after it for others) and confirm a lone legacy cell still loads. Reverting the dedupe fails the preference test.
• A new integration test pushes one app on two branches (master and 2.54) in a single push-oci run against a local registry, then builds the site and asserts both refs reach index/static, both .flatpakref files are generated, the dotted branch reaches its record with the sanitized tag, and no legacy cell is written.

Impact

• No migration needed. Existing records keep loading and the branch-qualified cell simply wins when both are present.
• No API, config, or OCI tag changes. The records dir layout from fix(record): include branch in the cell directory path #162 is unchanged.