fix(processing): count processed events in the messages-processed metric

[usmanimamu17-create]

Summary

Closes #521

xstreamroll_messages_processed_total was always zero: incrementProcessed() had no production caller. The worker's per-event success path (StreamSession.pump() in xstreamroll-processing/src/session.ts) emitted a "processed" event after a successful publish but never touched the metrics module, so processed-vs-failed counts were unobservable. This change increments the counter in pump() immediately after publish() resolves — after any retries, and never for dead-lettered events — so the metric reflects exactly the events the worker successfully delivered.

Why

The counter existed and was documented in the README's xstreamroll_* metrics, but the only thing that ever incremented it was its own unit test. Wiring the increment into the success path of pump() (rather than, say, subscribing to the "processed" event in the worker) keeps the metric truthful at the point of delivery: the session already owns the retry/dead-letter decision, so placing the increment next to the success break makes it impossible for a retried or dead-lettered event to double-count or count at all.

What was built

xstreamroll-processing/src/:

File	What it contains
session.ts	incrementProcessed() called in pump() right after await this.handlers.publish(processed) succeeds (the only change to production code; the import is the only new line).

xstreamroll-processing/__tests__/:

File	What it contains
session.test.ts	3 new tests: increments once per successful publish; increments exactly once when a transient failure succeeds on retry (3 attempts, 1 increment); does not increment for dead-lettered events. Also moved the mid-file fast-check import to the top to satisfy import/order.

No other files modified — the change is purely additive to one production file plus its test.

Acceptance criteria coverage

• Every successfully published event increments messagesProcessed exactly once, including after a transient publish failure that succeeds on retry (session.test.ts — "increments exactly once when a transient failure succeeds on retry", asserts 3 publish attempts → 1 increment)
• Dead-lettered events (retry budget exhausted) do not increment messagesProcessed (session.test.ts — "does not increment messagesProcessed for dead-lettered events", asserts counter unchanged after a dead-letter)
• GET /metrics on the worker's metrics server reflects the incremented value after events flow through a session (the counter lives in the same module startMetricsServer reads; metrics.test.ts still passes and the new session tests read getMetrics() directly)
• A test asserts the increment fires on success and not on failure (session.test.ts — new issue Worker messages-processed metric is always zero: incrementProcessed has no production caller #521 describe block)

Test plan

• cd xstreamroll-processing && npm test — 123/129 passing; the 6 failures are in pipeline.integration.test.ts and worker.integration.test.ts and reproduce identically on the base commit (verified via stash) — pre-existing, unrelated to this change
• cd xstreamroll-processing && npm run typecheck — clean
• npx eslint --config ../eslint.config.js src/session.ts __tests__/session.test.ts — 0 errors, 0 warnings (both files pass the repo's --max-warnings=0 gate)
• Targeted run jest session.test.ts metrics.test.ts — 37/37 passing (3 new tests)

Env vars / Notes

None — no new configuration. The 6 failing integration tests in this workspace are pre-existing (they fail on the base commit too); a separate issue tracks the worker integration-suite state.

[Xhristin3]

LGTM