kcode-kweb-manager 0.1.1

Kennedy's typed application manager for one live Kweb database
Documentation
# kcode-kweb-manager

`kcode-kweb-manager` is Kennedy's sole application owner of one already-opened
`KwebDb`. It provides typed reads, idempotent provenance and node mutations,
opaque object storage, and atomic session commits.

```rust
let manager = kcode_kweb_manager::KwebManager::open(
    database,
    "data/application.sqlite3",
)?;
let node = manager.get_node(node_id)?;
let (bytes, creating_provenance) = manager.get_object_with_provenance(object_id)?;
```

`get_object_with_provenance` returns exact object bytes plus the provenance from
the object's signed creating Kweb transaction. The manager does not retain a
second provenance record. When opening a receipt database created by the
predecessor implementation, it deletes that implementation's obsolete
duplicate-provenance table.

The caller remains responsible for opening Kweb, application root policy,
bootstrap nodes, HTTP routes, request and response formats, object-envelope
interpretation, and application validation.

Ordinary node creation and updates accept `NodeContents`, which deliberately
has no object field. Creates begin without objects and updates preserve the
node's existing objects. Object attachment remains part of the atomic
`kcode-commit-session` boundary.

Node transaction provenance embeds the stored provenance data when its UTF-8
byte length is at most 1 MiB (1,048,576 bytes). Above that threshold it embeds
a reference to the provenance object instead; the original envelope remains
available through `get_object`.

`create_provenance`, `create_node`, and `update_node` require a 32-character
lowercase hexadecimal idempotency ID. Reusing an ID for the same operation and
all the same input, including every storage-provenance field, returns its
original result. Reusing it for different input, or retrying a mutation whose
outcome was not durably recorded, returns `Conflict`.

All operations are synchronous. `KwebManager` is cheaply cloneable, but the
underlying database handle and idempotency lane remain private and shared by
every clone. The crate has no HTTP, JSON, Serde, async runtime, secrets, root
registry, authorization, or context-projection API.