persistent_term storage layer for erli18n translation catalogs.

Each loaded {Domain, Locale} catalog is stored as ONE persistent term: key {erli18n_catalog, Domain, Locale}, value a single map holding

• {singular, Context, Msgid} => Translation
• {plural, Context, Msgid, Index} => Translation
• '$header' => header_state()

Reads are copy-free (persistent_term:get/2 does not copy the term onto the caller's heap) and lock-free from the caller process. The read semantics mirror the previous ETS reads byte-for-byte: a missing catalog or a missing key both yield undefined, and the plural read evaluates the compiled rule (or the C/Germanic fallback) exactly as before.

Read-path rule (load-bearing)

Call persistent_term:get/2 FRESH on every lookup and let the returned map be transient. NEVER cache the catalog map in a long-lived process's state or process dictionary: a process holding the old term is forced into a major (fullsweep) garbage collection when the catalog is reloaded, and would serve a stale catalog. (erlang.org/doc/apps/erts/persistent_term.html, Best Practices.)

Reload cost

put_map/3 (install/reload) and unload/2 (persistent_term:erase/1) of the catalog map defer a node-wide literal-area cleanup: every process still referencing the old map runs a major GC, and all processes are made runnable to scan their heaps. It is paid once per (re)load — acceptable for erli18n's load-once-at-boot workload, but it is a real cost that ETS did not have.

The loaded-catalog index term (?INDEX_KEY) is written on the same node-wide basis only when its ordsets set actually changes: the first load of a {Domain, Locale} pair and the unload of the last reference to it each pay one index persistent_term:put (and its literal-area cleanup), but a reload of an already-indexed catalog skips the index write entirely (compare-before-put), so a steady-state reload pays the cost of the catalog-map term only.

Why the default-available index is NOT cached here

The per-request locale-negotiation default-available path rebuilds a canonical available_index from loaded_locales/0 on each request. Caching that prebuilt index as a SECOND persistent_term keyed off ?INDEX_KEY was considered and DELIBERATELY REJECTED. The per-request work it removes is marginal (one copy-free index_get/0 plus a usort/canonicalize over the tiny index) and is ALREADY fully avoidable by an application passing an explicit available option (the per-request thunk then returns it directly, with no rebuild). A cached term, by contrast, would add a recurring cost: a second persistent_term:put that must fire in lock-step with ?INDEX_KEY on EVERY index change (first load of a pair, last unload, and the header-only-reload index_del path), each scheduling the node-wide literal-area GC that the compare-before-put discipline exists to minimize. It would also widen the lock-step invariant surface (across put_map/3, unload/2, index_update/2, erase_all/0) and need ?INDEX_KEY-style namespace exclusion. A marginal, easily-avoided per-request saving traded for recurring reload-time node-wide GC plus added invariant/bug surface is premature optimization, so the index is recomputed per request rather than cached.