[pournasserian]

Closes #2515

What

The next F-CNT (#2416) slice: change sets hold operations on entries and entities, and diff, publish and revert them like schema operations (CHG-01, CHG-03, CHG-05, CHG-06). Builds on atomic publish (#2482) and revert (#2511). This is the first thing that moves Entries.PublishedVersion.

• Item kinds: an entry operation must point at an entry of a plain content type, and an entity operation at an entry of an entity type, in each case of a type the agent's scope allows for the operation (MCP-05). The wrong kind fails with the new item_kind_mismatch. A missing or soft-deleted entry fails with item_not_found, and a missing version with version_not_found. change_set.operation_added carries the base version's row as previous version, as for schema items. Other kinds (media, rules) are still item_kind_unavailable.
• Diff (ItemDiff.ForEntry in Core): two versions of an entry, field by field, with ValueDiff.Compare. On an entity a field's value is its whole fact, so a new source shows as a change. Fields follow the definition the shown version was written against, so the order is the same on SQLite and PostgreSQL even though jsonb reorders keys. DiffAsync reads every version the entry operations name, with their definitions, in one query.
• Publish: each entry's published version moves from its operation's base version to the proposed one with a conditional update, alongside schema items in the same unit of work. Stale bases fail with base_version_stale before anything moves, and a soft-deleted entry fails with item_not_found. Events: entry.published / entry.unpublished, or entity.*.
• Delete means unpublish: a published delete clears the published version and keeps the entry, its draft and its history. Revert of a create unpublishes, and revert of a delete publishes the base version again, through the same publish.
• One history per entity: EntryDirectory now names entries of entity types entity in its events (entity.created, entity.updated and so on), so an entity's own events and the change set events about it share a subject.

Why

Entries were stored and versioned (#2491) but nothing could put them live. Publishing through change sets keeps CHG-05's all-or-nothing rule for mixed sets of schema, entry and entity items (CHG-09), and revert comes for free from ChangeOperation.Inverse.

Choices worth a look:

• Separate kinds for entries and entities let the desk and blast radius (ENT-04) tell content changes from fact changes, without a lookup per item.
• A published delete unpublishes rather than soft-deletes, so its revert only has to move a pointer back. Soft delete stays a direct action with its retention window (Soft delete and restore entries within the retention window #2502). The entry states slice will call an unpublished entry archived.
• Writes do not join change sets themselves yet. A write stores a draft version and an operation points at it, as content types did before SCH-05. Entry writes will follow the change set target that Add the write tools for change sets and content types #2514 introduced, together with the entry tools.
• Changes to the F-CHG lane's file are kept in separate methods (ResolveEntryAsync, EntryDiffsAsync, PublishedEntriesAsync, PublishableEntry), so the SCH-05 work merges easily.

Tests

Unit (Core):

• ItemDiff.ForEntry: changed fields in definition order, with a removed field the type no longer has last; formatting-only differences ignored; facts compared whole; create and delete; refusal of non-entry operations and of fields that do not match the operation's versions.

Integration, each on SQLite and PostgreSQL:

• An agent cannot add an operation on an entry of a type outside its scope.
• Entry and entity operations stored with their kinds and events; the wrong kind both ways, a missing entry, a soft-deleted entry and a missing version each fail and write nothing; an update's event carries its base version's row.
• The diff of an entry update and an entity create.
• Publishing moves both pointers with one event per item; a resolved view follows the published price, not a new draft; an entity's own and change set events share its history.
• A stale base and a soft-deleted entry fail the publish and move nothing.
• A published delete unpublishes and keeps the entry; its revert publishes it again and marks the delete reverted.
• Reverting an update puts the earlier version back, and its diff shows the change backwards.
• A failure injected at each audit append of a publish leaves no entry published.

The full suite ran locally against a postgres:17 container as well as SQLite, after merging the latest v2. No migration, no new package and no new project reference.

Checklist

• Linked to an issue a maintainer has confirmed
• Targets v2
• Tests or docs updated where behaviour changed
• No tool-generated co-author trailers or footers