Query DB: measure repeated legacy-owner key parsing #2181

Observation

PR #2134 performs one persisted-row metadata scan per sync run, but getLegacyOwnerHashes then builds a candidate set from every persisted owner hash and every retention marker and JSON-parses candidates for each eligible equality demand (packages/query-db-collection/src/query.ts). This gives repeated work proportional to demands × (owners + markers), including fresh installs with no historical alias. The current oracle bounds scan count but not this parsing work.

This is a source-level performance concern; no user latency regression has been measured. Keep the correctness repair in #2134 focused.

Follow-up

Measure load cost across increasing owner and demand counts, including marker-heavy storage. If material, build the normalized historical-key index once per relevant metadata generation, with explicit updates when owners or markers change. Preserve the current static-key prefix and full-demand checks and the markerless-owner migration witness.