feat: offline queue — persist, batch, and flush events when connectivity returns

[alirezat66]

Summary

Add an offline-capable event path: when the device has no network (or delivery to trackers is impossible), store events safely and send them when connectivity and policy allow.

Problem

• Events can be lost during offline / flaky networks if trackers fail synchronously or the pipeline does not buffer.
• Teams need predictable semantics for ordering, caps, and consent while queued.

Goals

• Durable best-effort delivery for eligible events (policy-driven).
• Bounded memory/disk usage with explicit overflow behavior.
• Clear interaction with consent, routing, and sampling on flush.

Non-goals (MVP)

• Full “analytics database” product; start with a small, auditable queue.

Acceptance criteria

• Offline capture: when offline (or “cannot reach trackers”), eligible track calls are queued instead of dropped (per documented policy).
• Online flush: when connectivity returns, queued items are processed in a documented order without deadlocks.
• Backpressure: max queue size / storage cap; overflow behavior is documented and tested (drop oldest / drop newest / sample / stop queueing — pick one and justify).
• Consent: behavior defined + tested when consent changes while events are queued (e.g. drop now-disallowed events).
• PII safety: events flagged as PII are handled per policy (e.g. never persisted unencrypted / never queued without consent — document).
• Tests: unit tests for queue + flush; at least one integration-style test with simulated connectivity.
• Docs: README section + CHANGELOG note (limits, platform caveats, storage expectations).

Notes / links

• Likely overlaps with deferred tracker initialization queueing — consider a shared internal “outbox” design.

---

Implementation hints (optional)

- Consider a pluggable **OutboxStore** (memory + optional persistent impl). - Consider reusing / aligning with any future “pre-init queue” from deferred setup.