Reject an approved change set and publish items in a stable order #2616

Part of #2418 (F-CHG). A follow-up from the post-merge review of publish (#2482) and revert (#2511): an approved set whose publish has gone stale can never leave approved, and two publishes that move the same items in opposite orders can deadlock on PostgreSQL.

Scope

• Core (ChangeSetTransitions): add approved → rejected. As every rejection does, it needs a reason (CHG-08). People make it: agents are already refused it by Refuse agents' review moves and enforce change set caps #2503 (MCP-06), and no engine owns it (ADR-0012).
• An approved set that a person rejects takes its entries out of review. Entry states already read "in review" from the sets that hold an entry, and a rejected set holds nothing in review (CNT-01).
• Publish moves its items sorted by item kind and id rather than in operation order, so two sets that touch the same items take their row locks in the same order. The audit events keep the operation order.
• A PostgreSQL deadlock (40P01) or serialization failure (40001) during a change set write is answered with change_set_conflict instead of an exception, as a unique violation already is.

Out of scope

• Rebasing a stale set onto the version that is live now. A person rejects it and the author opens a new set.
• Rejection reasons as rule feedback (CHG-08, RUL-08), with F-RUL (F-RUL: Rule book as versioned content #2419).

Acceptance

• Two reverts R1 and R2 of one published set are both approved. R1 publishes. R2's publish fails with base_version_stale, and a person can then reject R2 with a reason. The entries R2 held are no longer in review, and the original set stays reverted once.
• An approved set is rejected only with a reason. An agent's attempt is refused and logged as for any other move it may not make.
• Two approved sets that update the same two items from the same base, listed in opposite orders, publish at the same time on PostgreSQL. One wins, the other fails with base_version_stale, and neither call throws.
• The transition table test lists approved → rejected, and every other transition stays as it is.
• All of the above passes on SQLite and PostgreSQL, and ProjectReferenceRulesTests pass with no new package.