The columnar index's key-interning root backend, as a held namespace
(`vaelii.impl.types.prover` states what that means).  `DenseRoots` mutates its own
fields, which only its inline methods can do, so the type and the code it calls live
here together; it calls only held namespaces.  Building one, and the snapshot sections
it is written into, are `vaelii.impl.dense-roots`.

The KB record, as a held namespace (`vaelii.impl.types.prover` states what that means).
A reload that redefined it would leave every open KB an instance of a class the reloaded
code no longer constructs.  Opening, closing and every operation on a KB is
`vaelii.impl.kb`.

The tiered handle posting — a sorted `int[]` while small, a `RoaringBitmap` past
`promote` — and the intersections over it, as a held namespace
(`vaelii.impl.types.prover` states what that means).  `IntPostings` mutates its own
fields, which only its inline methods can do, so the type and the code it calls live
here together.  The dense index backend (`vaelii.impl.dense-kv`), the columnar trie and
the dense TMS's adjacency columns store their handle sets in it.

The prover protocols, as a held namespace.

A held namespace is one the development browser's reloader never re-evaluates
(docs/web.md, *Hot reload*).  Re-evaluating a `defprotocol` defines a new interface and
empties the protocol's extension map, and re-evaluating a `defrecord` defines a new
class, so a loaded KB's registered provers would stop answering both.  This namespace
requires no vaelii namespace, so an edit elsewhere never reloads it as a dependent.

The prover records are defined, with their methods inline, in the namespaces that
implement them (`vaelii.impl.provers`, `vaelii.impl.calendar`, …).  The reloader leaves
a record that exists as it was loaded, so those namespaces reload too.

The two relation-algebra operations over masks, as a held namespace
(`vaelii.impl.types.prover` states what that means): the `IRelationOps` interface and its
dense and sparse implementations, which `vaelii.impl.qcn` compiles an algebra into.
The implementations are primitive loops over `long[]` tables and call no vaelii
namespace, so their methods stay inline.

The `Reasoning` record and its readers, as a held namespace (`vaelii.impl.types.prover`
states what that means).  A KB holds one `Reasoning` value in a volatile under its
`:reasoning` field: the belief network, the taxonomy, and every atom a recover or a
settle fills.  `vaelii.impl.kb/empty-reasoning` builds an empty one.

A `Reasoning` value is not a store.  A KB's two stores, `:records` and `:index`, are
durable and are reached through `vaelii.impl.protocols`, and both survive the process
that wrote them.  A `Reasoning` value lives in this process alone:
`vaelii.impl.recovery/recover` rebuilds it from the records, as `vaelii.impl.reindex`
rebuilds the index from them.  `vaelii.impl.reasoning-image` writes one to a directory so
that an open can install it in place of a recover, and a KB that declines the image runs
the recover instead.

A background rebuild's install replaces the whole value with one `vreset!`
(`vaelii.impl.recovery`), so the belief a KB holds changes in one step.  A reader
that must read the network and the taxonomy of one belief reads them through one
dereference: `vaelii.impl.kb/read-view` returns a KB whose volatile holds the current
value and is never reset, and `vaelii.core`'s public reads run against it while an
install is pending.

Each reader below is inlined at its call site, so `(taxonomy kb)` compiles to
`(:taxonomy @(:reasoning kb))`: one field read, one volatile read and one field read.

The two sentex records, as a held namespace (`vaelii.impl.types.prover` states what that
means).  Every stored sentex is one of these, so a reload that redefined them would
leave a loaded KB's records unequal to every record built after it.  Building,
canonicalizing and reading a sentex is `vaelii.impl.sentex`.

The snapshot sink and source protocols, as a held namespace (`vaelii.impl.types.prover`
states what that means).  The three media the engine ships, and writing and reading an
index image through them, are `vaelii.impl.io.snapshot`.

The `Solver` protocol and the `Program` record a solve is handed, as a held namespace
(`vaelii.impl.types.prover` states what that means).  The local solver behind the
protocol, and `program`, which builds a `Program` from a KB, are `vaelii.impl.solve`.

The storage records with no methods (`Kind`, `TokenLog`, `Oplog`), as a held namespace
(`vaelii.impl.types.prover` states what that means), with the notes on their fields.

A store with methods — a record store, an index store, a key-value backend — is defined,
with its methods inline, in the namespace that implements it (`vaelii.impl.memory`,
`vaelii.impl.kv`, `vaelii.impl.disk.kv`, …).

The truth-maintenance types, as a held namespace (`vaelii.impl.types.prover` states what
that means): the `Justification` record and the dense network's adjacency columns.

The two `Tms` implementations, `RefTms` (`vaelii.impl.jtms`) and `DenseTms`
(`vaelii.impl.dense-jtms`), are defined with their methods inline in those namespaces.
`TmsColumns` is a `definterface`, so `HeapColumns` implements it inline, together with
the three posting helpers it calls.

The columnar index's mutable int-token trie, as a held namespace
(`vaelii.impl.types.prover` states what that means).  `Trie` mutates its own fields,
which only its inline methods can do, so the type and the code it calls live here
together; it calls only held namespaces.  The `IndexStore` over it is
`vaelii.impl.columnar`.