content authoring: drafts, entity publish model, shape-compatibility markers, authoring UI

[zgeoff]

Content authoring moves into the registry that #851 delivered: mutable drafts over the published append-only versions, an entity-level publish model, shape-compatibility markers for new mechanics, and an authoring UI — so a balance pass is authored, previewed, and published without touching the repo.

Player story

New monsters, items, and balance changes reach you in a steadier stream, because shipping them no longer waits on an engine release — the world grows between your sessions without you installing anything. A run you're in the middle of is never disturbed by a content drop: what you face and find stays exactly as it was when you began, and only your next activity picks up the new world, online or offline. In one sentence: content arrives on its own schedule while every run you play stays consistent from start to finish.

Scope

• draft state over the registry: drafts are mutable, publishing mints an immutable version; write-once stays enforced at the schema layer
• entity-level authoring model (a monster/item/affix is immutable once published; a nerf is a new revision) with the publish step compiling entities into the version's content document
• each version carries a shape-compatibility marker: data publishes freely, but a new mechanic (a new field or behavior the interpreter must understand) still rides a deploy — interpretation code stays pinned by simVersion
• authoring UI over drafts and publish, replacing the interim content:publish JSON-file script as the authoring path
• the DB becomes the source of truth for published content: new versions never enter the repo; the migration's v1/v2 seed literals remain frozen genesis data

Notes

• Built on content registry skeleton: DB-backed versions, script publish, pinned loading #851, which delivered the storage and delivery skeleton: content_versions/content_current tables, script publish, startActivity stamping, pinned verifier loading, and version-keyed client fetch with offline persistence.
• content registry skeleton: DB-backed versions, script publish, pinned loading #851 deliberately shipped no retention machinery (documents are tiny and every stamped version stays loadable); revisit only if the entity model changes that calculus.
• The shape-compatibility markers replace gate startActivity on engine-content compatibility #848's interim machinery: the hand-maintained BUNDLED_CONTENT_VERSION constant and the sim_versions.max_content_version stamping at deploy-reconcile. Until then that constant is bumped by hand in the PR that adds a version's support code — drift is unguarded, and the gate refuses starts the engine could actually serve.
• Delivery-at-scale work (version manifest, content-addressed chunks, partial loading) is content delivery at scale: version manifest, content-addressed chunks, partial loading #856, blocked on this issue — its manifest is what the publish step here would compile.
• Non-goals: moving interpretation into data (derivation, draw order, and validation schemas remain shared-lib code).

[zgeoff]

Core skeleton (registry tables, script publish, stamping, pinned loading, client fetch) extracted to #851 and pulled forward to P3 — in-code content versions ride the engine-hash bundle, so any balance tweak during worldmap tuning would mint a sim version and a replay provider. This issue keeps the draft/publish workflow, shape-compatibility markers, and authoring UI on top of those tables.