Owns the receipts ETS table, and does nothing else.

An ETS table dies with the process that created it. The first version created it lazily from record/1, which runs inside Mob.Screen.Server.handle_call — so the owner was whichever screen happened to dispatch the first event of the app's life, and every held receipt was destroyed when that screen was popped. Not at 256, at zero, with dropped/0 still reporting 0 — exactly the "no receipt for that id" ambiguity Mob.Agent.Receipts says it eliminates.

Worse in the case that matters most: if the screen owning the table is the one whose handler raises, the crash receipt written on the way out is destroyed microseconds later by the same crash.

Started with GenServer.start/3 rather than start_link/3, and never linked: a diagnostic must not take a screen down with it, and must not die when one dies. mob has no supervision tree of its own — it is a library inside someone else's app — so Mob.Agent.Receipts.start/0 starts this on demand and tolerates {:error, {:already_started, _}}, the same shape Mob.Test.ProcessHelpers.ensure_component_registry/0 uses for the same reason.