fix handling of multiple sequential edits

[atennak1]

Bug: Syntax Tree Corruption with Incremental Edits

Problem

When users typed quickly or made multiple edits in a single change event, the syntax tree became corrupted with ERROR nodes and nodes containing ": null" text. This caused incorrect follow-up (after the first) code action edits and application.

Root Cause

The didChangeHandler was using the final document content to calculate edits for each incremental change. Since each change's range was calculated
against intermediate content states, applying them with the final content caused incorrect edit positions and tree corruption. This was seemingly not a problem for manual code edits as the handler was probably only receiving one incremental update at a time, but a code action with multiple edits triggers this bug.

Buggy code flow:

1. Extract to Parameter code action applies mutiple edits around the same time. In my case, 8 changes arrive to the DocumentHandler.
2. Handler gets content = textDocument.getText() (final state)
3. For each change, calculates edit using createEdit(content, change.text, start, end)
4. All edits use the same content, but ranges assume intermediate states
5. Tree becomes corrupted with ERROR nodes and corrupted strings

Solution

Track the current content state and apply each change sequentially:

1. Start with current tree content (or empty if no tree)
2. For each change, calculate edit using current content state
3. Apply edit to tree with the new content after that specific change
4. Update current content for next iteration

This ensures each incremental edit is applied correctly with proper content state, maintaining tree integrity while preserving performance through tree-sitter's incremental parsing.

Changes

• src/handlers/DocumentHandler.ts: Fixed to apply edits sequentially with correct content state
• src/context/syntaxtree/SyntaxTree.ts: Added getRootNode() public method for testing
• tst/unit/handlers/DocumentHandler.test.ts: Added test reproducing exact edit sequence from production logs, validates no tree corruption
• tst/resources/templates/sample_template_after_edits.json: Expected template state for test validation

Verification

• all existing unit tests pass
• multiple code action applications now valid
• autocomplete, hover, etc. continue to work

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[satyakigh]

I think lets hold off on merging this until we have all the bug fixes resolved from the release? This might require some in depth testing

[satyakigh]

Should this be cfnFileType !== CloudFormationFileType.Template ? we have gitsync, unknown, other and empty types now, don't think we need to do anything with gitsync files either

[atennak1]

Our current detection isn't perfect and we have lots of Completion tests that expect valid completions on templates even when cfnFileType !== CloudFormationFileType.Template