modify(): trailing inline comment is re-attached to the newly inserted property

Summary

When a new property is appended with modify(), a same-line (inline) trailing comment on the object's last property is re-attached to the newly inserted property. The comment then documents a different key, so the edit changes the meaning of the file, not just its formatting.

Environment

• jsonc-parser: 3.3.1 Also reproduces on 4.0.0-next.2 see the first comment with updated attachment
• node: v22
• Reproducible on any OS (pure string manipulation, no I/O involved).

Steps to reproduce

import { modify, applyEdits } from 'jsonc-parser';

const input = `{
  "host": "localhost",
  "port": 8080 // default port
}`;

const edits = modify(input, ['debug'], true, {
  formattingOptions: { tabSize: 2, insertSpaces: true }
});

console.log(applyEdits(input, edits));

(The behavior is identical whether the package is loaded via import or require.)

Actual behavior

{
  "host": "localhost",
  "port": 8080,
  "debug": true // default port
}

The // default port comment clearly belongs to port, but it is now attached to debug: true, where it makes no sense.

Expected behavior

{
  "host": "localhost",
  "port": 8080, // default port
  "debug": true
}

The comment should stay with port, and the new property should be inserted after it.

Scope

Triggers when: the last property of an object has an inline (same-line) trailing comment and a new property is appended.

Does NOT trigger when:

• the comment is on its own line, or
• the inline comment is on a non-last property.

So only the inline comment of the last property is affected.

Likely cause

The insertion point appears to be computed immediately after the last property's value token. The original trailing comma and the inline comment that follow it are left in place, so the inserted text lands before them — which visually re-associates the comment with the newly inserted property.

Related issues

• #76 — Option to keep spaces before inline comments: same area (inline comments handled by modify), but that report is about lost spacing/alignment, whereas this is about the comment being moved onto the wrong key (a semantic change).
• #51 — modify ... capture too much content: also about modify affecting content beyond the targeted node.

This seems distinct enough from #76 to warrant its own issue, but I'm happy to consolidate if you prefer.

jsoncbugdemo.zip

Start with the provided modify() and applyEdits() reproduction, then trace how modify() chooses the insertion point after the last property value and handles trailing inline comments. Done means the comment remains attached to port, the new debug property follows it, and the scoped cases continue to behave as described.