Init-and-idle GenServer owning the :mailglass_inbound_rate_limit ETS table (cloned from Mailglass.RateLimiter.TableOwner, D-22 crash semantics). Owns nothing beyond ETS table creation — no handle_call/3, handle_cast/2, or handle_info/2. Hot-path reads/writes happen directly from caller processes via :ets.update_counter/4 — NO GenServer mailbox serialization.

ETS opts (OTP 27+) — copied verbatim from core

• :set — single-entry-per-key bucket
• :public — cross-process read/write without owner-forwarding
• :named_table — caller references :mailglass_inbound_rate_limit directly
• read_concurrency: true — hot read path optimization
• write_concurrency: :auto — OTP 27 flag for lock striping
• decentralized_counters: true — OTP 27 flag, per-scheduler counters

Crash semantics (D-22)

If this process crashes, BEAM deletes the ETS table. Supervisor restarts TableOwner; init/1 calls :ets.new/2 anew. Counter state resets to empty — acceptable per D-22: "rate-limit state is not load-bearing across crashes." Worst case is 1 minute of burst allowance until refill restarts.

LIB-05 note

This module uses name: __MODULE__. It is library-internal machinery (not a user-facing singleton) and is the documented LINT-07/LIB-05 reserved-singleton exception, mirroring Mailglass.RateLimiter.TableOwner. The inbound ETS table must be a process-stable named table so the limiter hot path can reach it without a registry lookup.