Concurrent editing

## Goal

Multiple editors working on the same Cortext record (page, collection schema, or entry) merge their changes cleanly. Covers three modes: real-time co-editing when both are live, atomic concurrent saves when they aren't (two tabs, two devices, two users saving close in time), and offline-then-reconcile when one goes away and comes back. No save clobbers another.

## Scope

Adopt WordPress 7.0's built-in sync engine (`@wordpress/sync`, Yjs-based) across Cortext's three editable surfaces: pages, collection schemas, and collection entries. Use the auto-applied post-type sync config wherever it suits, and write custom configs only where it doesn't.

Activation goes through `WP_ALLOW_COLLABORATION` plus the `wp_collaboration_enabled` site option. Default HTTP polling provider, no custom transport.

## Out of scope

* Custom sync providers.
* Awareness avatars, collaborator cursors (ship in core; Cortext inherits).
* Per-entity-type RTC toggles in admin UI.
* Block-level commenting (separate experimental track).
* Building our own CRDT for non-CPT entities (Cortext doesn't have any).

## Calendar

WP 7.0 RC3: May 8, 2026. WP 7.0 GA: May 20, 2026. Implementation can start against trunk now; revalidate against RC3 once it lands.

Start by inspecting Cortext's page, collection schema, and collection entry editing entry points, then review WordPress 7.0's @wordpress/sync integration, auto-applied post-type sync configuration, WP_ALLOW_COLLABORATION, and the wp_collaboration_enabled site option. Done means real-time edits merge, concurrent saves do not clobber changes, and offline edits reconcile across all three surfaces using the default HTTP polling provider; revalidate against WP 7.0 RC3.

Written by the indexing model from the issue text.