Harden retry backoff in event processor: cap delay, add jitter, and use overflow-safe math

[jgmontoya]

Summary
The current retry backoff is purely exponential, which risks overflow and synchronized retries ("stampedes"). We should harden the strategy by capping the delay, adding light jitter, and ensuring overflow-safe arithmetic. Include the event ID in retry logs for traceability.

Context

• Requested during review of PR Feat/global user subs #340 (Feat/global user subs).
• Requester: @jgmontoya
• PR: Feat/global user subs #340
• Discussion: Feat/global user subs #340 (comment)

Scope

• Retry scheduling for event processing (keep changes out of PR Feat/global user subs #340; track and deliver in a separate PR).

Acceptance criteria

• Exponential backoff uses overflow-safe arithmetic and clamps to a sensible maximum delay.
• Add small jitter per event to avoid thundering herd effects.
• Retry warnings/logs include the event ID for traceability.
• Unit tests cover delay capping, jitter bounds, and absence of overflow at high attempts.
• Consider simple configurability for max delay and jitter percentage (constants or config).

Notes
Please link the implementing PR back to this issue upon submission

[erskingardner]

@jgmontoya do you want to keep this open?

[jgmontoya]

@jgmontoya do you want to keep this open?

TBH this feels like overengineering, I think we should close it and come back at it if it ever becomes an acutal issue