kcode-kweb-context 0.2.0

Typed Kweb node context and Chatend box projection policy
Documentation
# API and behavior

`Node::from_kweb_value` converts a Kweb node response into a typed, validated
node. `Context` retains explicitly loaded nodes and their fixed connections.
Explicitly loaded nodes take precedence over the fixed role.

`Context::apply_load` accepts one fetched node plus the full nodes fetched for
its fixed connections. `Context::restore` reconstructs the same state from
stored nodes and the ordered IDs established by prior `LoadNode` invocations.

`Context::sync_chatend` accepts an already-open Session History session,
the caller's timestamp, and staged updates and creates. It reconciles the
complete provider-facing Kweb projection:

1. one `Loaded` full-node box per explicitly loaded node;
2. one `Fixed` full-node box per distinct fixed connection not already loaded;
3. one `Staged` full-node box per staged create; and
4. permanent `Recent` summary boxes containing at most eight globally
   deduplicated recent connections each.

Loaded, fixed, and staged boxes share the same body formatter. They differ only
in their declared box name and typed metadata. There is no active-node role or
active-connection field.

New recent connections fill the newest partial summary box before another is
created. Full summary boxes retain their exact membership and canonical text.
Existing recent boxes are never retired, and caller-selected summarized or
dehydrated representations survive canonical updates. The returned box IDs are
exactly the boxes whose active name or canonical revision changed, in current
projection order.

The caller remains responsible for fetching Kweb data, choosing roots and
staged mutations, deciding when to synchronize, and committing the resulting
Kweb transaction. The crate uses the supplied Session History handle only to
apply its projection; it does not open persistence, use HTTP, or access Kweb.