#3979 Extension scoring queue: two replicas can claim the same pending event

Problem

The extension scoring queue claims work in two steps with no lease. In lib/infrastructure/mongo-extension-scoring-event-queue.ts, fetchPending runs a find for pending (or failed, under 5 attempts) rows sorted by createdAt, then a separate updateMany that marks them processing. Every replica runs the watcher (lib/infrastructure/extension-scoring-event-queue-watcher.ts, started from main.ts, batch 10, 5 s poll), so two replicas that poll between each other's find and updateMany both take the same rows.

Impact

Each event re-downloads the tarball, runs deno doc and lint subprocesses, and makes up to 50 npm/OSV queries (lib/app/process-extension-scoring-event.ts, 3 per replica, 3 minute timeout). A duplicate claim runs all of that twice and races two upserts of the same extension_version_meta row. With one publish at a time this is rare. A bulk enqueue makes it routine: the RUBRIC_VERSION 5 rescore from swamp-club#3977 would queue about 2,000 current versions at once.

Expected

An event is processed by one replica at a time: claim it atomically (findOneAndUpdate per row, or a claim token written and then read back), keeping the 5 minute stale-processing reclaim.

Found while triaging swamp-club#3977.