[pournasserian]

Closes #2521

What

The next F-CNT (#2416) slice: entries have the CNT-01 states (draft, in review, published, reverted and archived), and only change sets move them. Builds on entry operations in change sets (#2519).

• Core (FluentCMS.Core.Content): EntryState, carried by Entry and EntrySummary. EntryStates.Review lists the change set states that hold an item in review (checks running, checks failed, awaiting review, approved). EntryStates.AfterPublish says what a publish leaves an entry as: published for a create or update, archived for a delete, and reverted for any item of a revert.
• In review is read, not stored: GetAsync and ListAsync show an entry as in review while any set in a review state holds an operation on it. The query is one subquery on ChangeSetOperations and ChangeSets, so two sets reviewing one entry keep it in review until neither does, and a rejected or reopened set gives it back its earlier state with nothing to undo.
• The other states are stored in Entries.State and written only by publish, in the same conditional update that moves the published version. A new entry starts as a draft. IEntryDirectory has no way to set a state, and writes, soft deletes and restores leave it alone.
• Migration for SQLite and PostgreSQL: State defaults to Draft, entries that already have a published version become Published, and a check constraint allows only the four stored states.

Why

CNT-01 wants states that only governance moves. Storing only what publish decides, and reading in review from the sets themselves, means no write path can change a state, and there is no remembered "state before review" to get wrong when sets overlap.

Choices worth a look:

• A published entry with a newer draft is still published. The state describes what is live; the pending draft shows in LatestVersion against PublishedVersion.
• Checks failed counts as in review, because the set is still on its way to a decision: it either goes back to open, which ends the review, or gets rejected.
• Every item of a published revert is reverted, whether the revert republished it or took it offline, so the desk's reverted view (DSK-02) can find them.

Tests

Unit (Core):

• A new entry is a draft; a revision keeps the published version and the state; Restore takes the state.

Integration, each on SQLite and PostgreSQL:

• Draft while its set is open, in review through checks running, checks failed, awaiting review and approval, draft again when reopened, published when published; GetAsync and ListAsync agree at every step.
• Two sets review a published entry; rejecting one keeps it in review, rejecting both shows it as published with its pending draft.
• A published delete archives the entry, its revert makes it reverted, a published update makes it published, and that update's revert makes it reverted.
• A new draft, a soft delete and a restore leave a published entry published.
• The migration turns an entry that already had a published version into published and leaves the other a draft, and the newest migration's Down works on both providers.

The full suite ran locally against a postgres:17 container as well as SQLite. 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