Decide the package split, measured (#746 item 78) (#1023)

Docs/Contributing/Packaging.md: what the four published packages contain and
depend on, what the kernel is made of by subsystem, what a caller measurably
pays for it, the criterion that decides where the next capability goes, that
criterion applied to what is in the kernel and to what the roadmap says is
coming, what each move would cost users, and the dependency rules between
packages with the two cheapest ways to enforce them.

The decision is that the boundary is drawn on dependencies, not on size. Two
measurements settle it. A trimmed self-contained app that only parses and one
that parses and simplifies get a byte-identical kernel assembly, 852,480 B; an
app exercising thirteen entry points gets 951,808 B, so the whole spread between
the narrowest and the broadest use of the library is 8.4% of one assembly, and
the startup cost is first-call rather than load. Splitting managed code out of
the kernel therefore buys almost nothing and costs a permanent version matrix,
while a capability that brings a native payload, a newer framework floor or a
data corpus costs the common case whatever it does not use.

Every figure is derived on this checkout with the command beside it. The kernel
is 211 files and 53,665 lines, one of which is a documentation file the default
glob compiles. SymPy export is not a recent arrival: it has been an abstract
member of Entity since before v1.4.0. Eleven capabilities are abstract members
of Entity and 68 node types implement each, five of the eleven inaccessible
outside the assembly, so domain packages are blocked on an extensible node
contract rather than on a packaging decision. A NativeAOT publish of the broad
app emits no trim or AOT warning and prints byte-identical output.


Claude-Session: https://claude.ai/code/session_01Bjumi5K7fg8yx6UK1mZTQd

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Rafael-SOWNet