Match installed catalog apps by trusted repo identity

[hamzamerzic]

Problem

The App Store decides whether a catalog entry is installed by matching its canonical <repo>#manifest-id=<id> key against installed rows. The <id> is volatile — it skews against the persisted install row whenever:

• the catalog advertises main while the row is pinned to a reviewed commit,
• the baked manifest snapshot is stale and its live refresh has not landed, or
• the app's manifest was renamed (previous_id → id), which the backend already adopts in _select_install_target but the client matcher did not.

Any of these desynced both the "installed" label and the otherInstalledCatalogItems de-dupe from the backend, so a genuinely-installed app could render as Not installed and appear twice — once as a curated card, once under "Other installed apps".

Fix

findInstalled now matches on the stable per-repository identity for trusted mobius-os root manifests — the "one app per repository" invariant trustedCatalogRepoBase already encodes — instead of the manifest-id string. Repo identity survives commit pins, snapshot staleness, and renames, so the display and de-dupe stay aligned with the backend without a client-side mirror of previous_id.

Exact canonical-key matching still runs first, so non-mobius-os and repo-subdirectory manifests (which have no trusted repo identity) match precisely, and a null-manifest legacy row still matches nothing.

Tests

Adds coverage in tests/helpers.test.mjs:

• findInstalled matches across manifest-id skew (stale snapshot, rename, reverse rename) and stays repo-scoped (a different repo reusing the same id string does not match).
• otherInstalledCatalogItems emits no duplicate card for a curated app whose installed row has a skewed manifest-id.

All helper tests pass locally (node --test tests/*.mjs).

[miljanm]

Reviewer: all clear

I didn't find a concrete issue in this revision. This is a QA second look, not a maintainer approval.

Reviewed revision 33d987a011b9.