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 via the SDK's built-in TimerFlushPolicy (100ms interval), then polls pendingEvents() until the queue drains or timeout
• Reports accurate success (false when events remain in queue or were permanently dropped) and sentBatches (derived from delivered event count)
• Reads drop-count from logger.error() messages emitted by SegmentDestination when events are permanently dropped or retry-limit-exceeded
• Enables the retry test suite in e2e-config.json

Depends on #1156 (tapi/types-and-errors) for httpConfig on Config.

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.

What this fixes

• Retry tests that need basic retry → success pattern (500 → retry → 200)
• success field reporting (was hardcoded to true)
• sentBatches tracking (was hardcoded to 0)
• Error classification (permanent drops on 4xx vs retry on 5xx) via tapi types
• maxRetries wiring to httpConfig.rateLimitConfig and httpConfig.backoffConfig

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