[Markdown Agent] Apply document edits deterministically

[George Ng (GeorgeNgMsft)]

What changed

This PR adds the raw-Markdown edit engine that later persistence layers can call. It does not yet change where documents are saved or add browser synchronization.

Before

A model can return several edits whose character offsets were all calculated from the same original Markdown. The previous application path processed those edits sequentially against an already-mutated string, so an early edit could move the text targeted by every later edit.

For example, starting with ABCDE:

1. insert X at offset 1
2. delete original range [3, 5) (DE)

Applying those operations in request order produces AXBCDE, then deletes offsets [3, 5) from that changed string (CD), yielding the incorrect result AXBE.

The previous path could also reverse multiple inserts at one position, silently clamp invalid ranges, and apply intersecting edits whose meaning became ambiguous after the first mutation.

After

applyDocumentOperations treats the operations as one edit batch against one original Markdown snapshot:

• validates every character offset against the original text
• rejects intersecting operations before changing anything
• applies non-overlapping edits from the highest offset to the lowest, so edits later in the document cannot shift locations still waiting to be changed
• preserves request order for multiple inserts at the same position
• converts structured content into Markdown for insert/replace operations
• supports adding and removing strong, emphasis, inline-code, and link marks

For the example above, the delete at [3, 5) runs first and removes DE; the insert at 1 then produces the intended AXBC.

This follows the established simultaneous text-edit model used by language tooling. The LSP contract describes text edits against a document range, while Microsoft’s reference Node implementation sorts edits and applies them from the end toward the beginning, rejecting overlap:

• Language Server Protocol: TextEdit
• vscode-languageserver-node reverse edit application

Why this is a separate stack layer

The original replacement change combined edit semantics with file persistence, stale-write protection, and browser synchronization. Isolating the operation engine makes its coordinate contract and edge cases reviewable before later layers use it for durable updates.

Deferred upward: durable workspace persistence, revision and binding conflict checks, streaming exactly-once persistence, view-service state, browser synchronization/autosave, same-file editor rebinding, and loopback-only binding.

Validation

• cached TypeScript 5.4.5 strict no-emit check passed for markdownOperationSchema.ts and documentOperations.ts
• direct compiled smoke tests passed for base-relative edits, same-position inserts, overlap rejection, mark add/remove, balanced-parenthesis links, and mismatched-link preservation
• cached Prettier 3.5.3 changed-file check passed
• git diff --check passed

The normal package build/Jest suite and PR ratchets could not run because this worktree had no node_modules; the single time-boxed restore did not complete while reaching unavailable Azure feed artifacts. The commit hook was bypassed after the equivalent cached Prettier, type, and smoke checks above.