Background queue that batches payloads and flushes them on a timer.

Payloads for each URL key are accumulated in the GenServer state and sent in batches of up to 4 via DirectWriter on each flush tick. Batches (across all URL keys) are flushed concurrently, bounded by EndPointBlank.Config.worker_count/0 (default 4), so a flush tick never fires more than that many writes in flight at once.

Each URL key's queue is capped at 1000 payloads. If an intake outage (or any slow/hung downstream) causes payloads to accumulate faster than they can be flushed, the oldest payloads for that key are dropped to keep memory usage bounded in the host app.

A failing batch costs that batch, never this process

This is fire-and-forget telemetry embedded in someone else's application. Nothing it does may be able to stop that application, so every way a flush can fail is contained and reported rather than allowed to propagate:

• write_batch/1 catches inside the task, which is the only place a batch's failure can be stopped — see the note there for why a try around Task.async_stream/3 cannot do it;
• the flush callback guards what it evaluates itself, which includes EndPointBlank.Config.worker_count/0 — a config read that fails in this process, not in a task, when the config store is unavailable;
• a recovered failure is logged loudly, once per failing tick, and the tick interval backs off exponentially while failures continue, so a persistent fault reads as one escalating line rather than a hot loop.

The one thing deliberately left to propagate is an exit signal delivered to a task from outside it; write_batch/1 documents that boundary.