fix: handle incompatible operation lengths during client synchronization

[khush2706]

Description

Issue
Windows dictation/IME input in Monaco intermittently caused Firepad to throw OT validation errors such as:

The base length of the second operation has to be the target length of the first operation
sendOperation() called with invalid operation
This broke collaboration sync for affected typing sessions.

Root Cause
MonacoAdapter converts Monaco content-change events into OT operations.
For some IME/dictation change batches, the generated operation did not exactly represent the actual document transition (previous content -> current content). Once that malformed operation entered the OT pipeline, compose/merge invariants failed and eventually surfaced as invalid outgoing operations in the Firebase adapter.

In short: the failure was caused by incorrect operation construction from certain Monaco IME change batches, not by Firebase itself.

Fix
Hardened MonacoAdapter operation generation with validation + fallback:

• Build operations from Monaco change batches as before.
• Validate the generated operation by applying it to previous content and verifying it matches the editor’s current content.
• If validation fails (or change-batch conversion throws), fall back to a robust diff-based operation built from full previous/current content (common prefix/suffix + middle replace).
• Preserve inverse operation generation for undo/redo compatibility.
• Avoid mutating Monaco’s incoming changes array by sorting a copy (Array.from(changes).sort(...)).

Result
IME/dictation edits now always produce valid OT operations, preventing downstream compose/send invariant failures and keeping collaborative sync stable.

[devsebastian]

remove?

[khush2706]

@devsebastian I can change the version name to 0.8.6, is that fine?

[khush2706]

Will have to keep this as -alpha, getting this error otherwise

[devsebastian]

are these required?

[khush2706]

yes, was getting this error otherwise