ea2cf14f48
`dist ci publish` now seeds the Repo from a pre-existing <store>/db.json before find-or-create, so separate CLI invocations share state: a new version accumulates under the single found app, and re-publishing the same release id is rejected by the P2.3 integrity transaction (db.json left unchanged). An absent db.json still starts empty. The loaded model grows through its owning allocator (context.allocator), per the long-lived rule. Wiring db.load into the dist program (which already links manifest.sx) exposed two latent issues, both fixed: - db.sx's load-path helpers (dup_str/obj_find/req_obj/req_arr/ artifact_from_json) collided by name with manifest.sx's same-named helpers; sx resolves bare top-level names across the whole program, so load_into bound to manifest's versions and failed the LoadErr error-set check. Renamed db.sx's five helpers with a db_ prefix (load-path only; save path and public API untouched). - publish's `existing!.id` (only reachable once an app is found, i.e. never before this change) read garbage: sx miscompiles postfix-`!` chained with `.field`. Bound the unwrap to a local first, matching the codebase idiom. tests/publish_persist.sx drives build/dist twice into one store: publish A, then a different version B accumulates (two releases, one app, both objects), then re-publishing A's id fails and leaves db.json unchanged. Fails on the pre-fix write-only persistence, passes after.