RTC: Incompatible meta boxes disable collaboration UI but sync keeps running, hiding all error surfaces

[mmtr]

Description

When the editor detects an incompatible legacy meta box, useMetaBoxInitialization dispatches setCollaborationSupported( false ) (introduced in #75939). This flips a UI flag — but it does not actually tear down the sync manager. As a result:

1. Tabs continue to sync edits in real time, even though the editor reports collaboration as unsupported.
2. Any disconnect/error UI gated on isCollaborationEnabledForCurrentPost() (most importantly SyncConnectionErrorModal) silently returns null, so users never see errors that do fire — including connection-limit-exceeded from the per-room peer cap.

Net effect: when more than MAX_PEERS users open the same post, the (N+1)th user is silently ejected from sync with no visible feedback, while the first N continue collaborating normally. There is no UI signal anywhere that anything is wrong.

Steps to reproduce

1. Open the post editor for any post.
2. Open Options → Preferences and toggle Custom fields on. Reload the editor when prompted (this surfaces the built-in postcustom meta box, which is not marked __rtc_compatible).
3. Duplicate the editor tab 4 times so 4 tabs are open on the same post.

Expected behavior

Either:

• (a) Sync should actually be torn down when setCollaborationSupported( false ) fires — providers disconnect, awareness clears, no further syncing — matching the stated intent of RTC: Disable multiple collaborators if meta boxes are present #75939; or
• (b) The disconnect modal should remain capable of showing terminal sync errors (e.g. connection-limit-exceeded, network failures) regardless of the meta-box flag, so users always get feedback when sync fails.

Actual behavior

• Tabs 1–3 keep editing in real time. Edits in tab 1 appear in tabs 2 and 3 immediately.
• Tab 4 cannot edit collaboratively (its provider hits the peer limit and disconnects via checkConnectionLimit), but no modal appears.
• The user has no indication anything is wrong.

Diagnostic evidence

In tab 4's DevTools console after the editor has loaded for >20s:

wp.data.select( 'core' ).getSyncConnectionStatus()
// → {
    "status": "disconnected",
    "error": {
        "code": "connection-limit-exceeded",
        "name": "ConnectionError"
    }
}

wp.data.select( 'core/editor' ).isCollaborationEnabledForCurrentPost()
// → false

document.querySelector( '[class*=\"editor-sync-connection-error-modal\"]' )
// → null

The error reaches coreDataStore correctly. The modal is suppressed at SyncConnectionErrorModal:128 because isCollaborationEnabled is false — which is itself false because isCollaborationSupported() was flipped by the meta-box detection in useMetaBoxInitialization, even though sync is still very much running.

Suggested fix

The cleanest resolution is option (a) above: when setCollaborationSupported( false ) is dispatched, the sync manager should unload all entities so providers disconnect. That preserves the intent of #75939 (RTC truly off when incompatible meta boxes are present) and eliminates the "silent half-disable" state entirely. The modal-gating issue then becomes moot.

If teardown isn't desirable for some reason, then SyncConnectionErrorModal's render gate should not depend on isCollaborationSupported — terminal sync errors should surface whenever sync was started, regardless of the flag's current value.

Related

• RTC: Disable multiple collaborators if meta boxes are present #75939 — introduced the half-disable
• RTC: Add filterable flag for meta box RTC compatibility #76939 — added the __rtc_compatible_meta_box opt-in flag (mitigates for plugin authors who opt in, doesn't fix the underlying teardown gap)
• RTC: [Interface] Allow limiting Real-Time Collaboration to specific post types #75072 — broader RTC/meta-box scoping discussion

[mmtr]

cc @ingeniumed @alecgeatches