Score extension publish events in the telemetry pipeline

Closing — the functional ask here already ships end-to-end. Extension publishes contribute to the author's score via the same telemetry→queue→refresh pipeline pulls do; they just use a different data source.

Pipeline trace for a publish:

1. routes/api/v1/extensions/confirm.ts:110 fires track("extension_published", distinctId, { username, extension_name, version, ... }) after confirmPush succeeds.
2. services/telemetry/lib/server.ts:196 lifts properties.username into eventUsername and writes it onto TelemetryEventDoc.username.
3. services/telemetry/lib/watcher.ts:130 copies username onto the TelemetryEvent passed to the post-delivery callback.
4. services/telemetry/lib/queue-producer.ts:20 — if (event.username) usernames.add(event.username) — the author is enqueued to swamp_club_events. (The extension_pulled-specific fan-out added in #56 sits alongside this generic path, not instead of it.)
5. lib/infrastructure/event-queue-watcher.ts polls every ~5s → processScoreBatch → refreshUserScoreFromMetrics/FromApi → refreshExtensionScore.
6. lib/app/refresh-extension-score.ts:38-60 calls extensionRepo.countVersionsByUser(operative.id), runs computeExtensionScore, and contributes the result as a distinct content:extension-publishes entry — separate from content:extension-pulls, with its own 5000-point cap.

Scoring constants (lib/domain/scoring/extension-score.ts):

• POINTS_PER_PUBLISH = 500, MAX_PUBLISH_SCORE = 5000
• Pinned by tests/app/refresh_extension_score_test.ts:110 (2 versions → 1000 publish points).

The open questions in the issue map to design choices already made:

• Fixed vs. scaled points? → Fixed: 500 per non-yanked version.
• New scoring group or separate contribution? → Separate contribution id content:extension-publishes within the existing content.extensions group.
• Version updates score the same as initial publishes? → Yes — countVersionsByUser counts every non-yanked version regardless of whether it's the first.
• Deduplication on reprocessing? → Satisfied structurally: the telemetry event is only a refresh trigger. The score is recomputed from extensions.versions, which confirmPush guards against duplicates via the VersionConflictError check.

One thing the issue proposes that isn't implemented is the event-sourced award model (emit a scorable event, grant points per insert_id, persist as an award record). That's a different shape — it would decouple score from countVersionsByUser and give "yank doesn't claw back points" semantics. That's a legitimate design question tied to #227 and worth its own issue if we want it; it's not a gap in what this issue asked for.

Known adjacent gaps that are out of scope for this issue and should be filed separately if we want them:

• Collective-token publishes (pushedByUserId: null in lib/infrastructure/mongo-extension-repository.ts:685) don't score any member of the collective.
• No explicit queue_producer_test.ts case for extension_published — the path works by construction but isn't pinned against regression.

Closing as already implemented.