feat(e2e-cli): add flush-retry loop to simulate real flush policy

[abueide]

Summary

• Replaces the single flush() + 500ms wait with a proper flush-retry loop that simulates the flush policy cadence a real app uses
• The CLI now drives repeated flush cycles — flush → check pending → wait for backoff → repeat — until the queue is empty or maxRetries is exceeded
• Reports accurate success (false when events remain in queue or were permanently dropped) and sentBatches (computed from delivered event count)
• Forward-compatible with the tapi RetryManager: reads backoff state (READY / BACKING_OFF / RATE_LIMITED) and waitUntilTime when available; falls back to a fixed 100ms delay on master where RetryManager doesn't exist
• Enables the retry test suite in e2e-config.json

Context

The SDK uses a deferred retry model: failed events stay in a persistent queue and are retried on the next flush policy trigger (timer every 30s, count threshold at 20). The CLI had no flush policies running — it called flush() once and exited. Events that received retryable errors (5xx, 429) were left in the queue with no retry, causing ~20 retry e2e tests to fail.

This PR is independent of the tapi PR stack (#1156–#1160). On master, the SDK doesn't differentiate retryable from non-retryable errors (all non-2xx leave events in queue for retry), so the retry loop enables basic retry behavior. Full error classification, backoff timing, and X-Retry-Count headers require the tapi features.

What this fixes (on master)

• Retry tests that only need basic retry → success pattern (500 → retry → 200)
• success field reporting (was hardcoded to true)
• sentBatches tracking (was hardcoded to 0)

What still needs the tapi branch

• Error classification (permanent drops on 4xx vs retry on 5xx)
• RetryManager backoff timing (exponential backoff, Retry-After)
• X-Retry-Count header incrementing

Test plan

• esbuild build succeeds
• CLI smoke test with empty input returns {"success":true,"sentBatches":0}
• All 66 existing unit test suites pass (362 tests)
• Run e2e tests against mock server to verify retry loop behavior

🤖 Generated with Claude Code