resolve conflicts: #24743 chore: handle legacy duplicate opaque handles

[PhilWindle]

Automated conflict-resolution attempt for #24869 (fwd-port-24743). Merges next + v5-next PR #24743 ("chore: handle legacy duplicate opaque handles"). Review carefully.

What was resolved

yarn-project/kv-store/src/sqlite-opfs/store.ts had committed conflict markers in two hunks:

1. Imports — kept next's imports and added only chore: handle legacy duplicate opaque handles #24743's genuine addition, import { quarantineDuplicatePool } from './pool_integrity.js';. Dropped the incoming import { PoolLockLease, acquirePoolLock, normalizePoolDirectory } from './pool_lock.js'; line: that is pre-existing v5 baseline context (from feat: weblock controlled opfs pool #24740's Web Lock work), not part of chore: handle legacy duplicate opaque handles #24743, and next has no pool-lock support.
2. open() body — kept next's structure (worker/store created before the try with the 4-arg constructor, single transfer declaration) and inserted chore: handle legacy duplicate opaque handles #24743's quarantine block at the top of the try, keyed off next's existing poolDirectory parameter instead of the v5-only effectivePoolDirectory/poolLock locals.

store_management.test.ts was listed as a conflicted file but carried no markers on the branch (added cleanly by the cherry-pick); it was left untouched.

Important: this forward-port is incomplete and will not build as-is

PR #24743 was built on top of a v5-only stack that never landed on next. On next, yarn-project/kv-store/src/sqlite-opfs/ is missing:

• pool_lock.ts (provides normalizePoolDirectory, acquirePoolLock, PoolLockLease)
• manage.ts (provides deleteStore, listStores, storePoolDirectory)

The cherry-pick added pool_integrity.ts and store_management.test.ts, but both import ./pool_lock.js (and the test also imports ./manage.js), so the package will fail to compile until the underlying weblock/pool-management work (PR #24740 and any siblings) is also forward-ported. Resolving the markers cannot fix this — it needs those modules ported first, or #24743's feature scoped down to what next supports.

No generated artifacts were involved; no regeneration required.

Confidence

Low overall. The marker resolution within store.ts is correct and self-consistent, but the branch depends on modules absent from next, so it needs human judgment on how to complete (or split) the forward-port before it can build/merge.

[PhilWindle]

Superseded by #24918 — the v5-next→next backlog is now one time-ordered forward-port PR with a single resolution PR on top, instead of fragmented per-PR pairs (the fragmentation broke commit dependencies). Closing.