Retry uploads with exponential backoff

DecisionLogPlugin.DecisionLogs.flush drains the buffer into a batch and calls sendToService, which catches and logs exceptions. The drained events are then gone — a transient HTTP failure (503, network blip) silently loses the batch.

• Hold the batch separately from the buffer until the upload succeeds.
• Retry on failure with exponential backoff and a configurable max attempts.
• On final failure, surface a status event (depends on the future per-plugin status work) and either re-queue at the head of the buffer or persist (depends on the disk-persistence follow-up).
• Tests: 5xx then success retains all events; permanent failure surfaces an error and doesn't loop forever.
• Coordinates with #76 (bounded buffer) — a permanently failing upload should still respect the cap.

Start at DecisionLogPlugin.DecisionLogs.flush and sendToService, then review the existing upload and buffering tests. Check issue #76 and the planned per-plugin status and disk-persistence work before settling the final-failure behavior. Done means transient 5xx failures retain all events and eventually succeed, while permanent failures surface an error, terminate after the configured attempts, and respect the buffer cap.