[Terminal] Double-click word selection overruns into a following CJK fullwidth separator character

## Bug description

In the integrated terminal, double-click word selection **overruns by one cell into a following CJK fullwidth (double-width) separator character**: the selection (and anything copied from it) includes the separator, even though the selection boundary visually appears to stop at it.

Since the fullwidth character occupies two terminal cells, the overrun lands mid-glyph, so the wide character is only partially highlighted and is easy to miss at first glance — but it is part of the selection.

## Steps to reproduce

1. Add CJK fullwidth punctuation to the terminal word separators, e.g.:

```json
"terminal.integrated.wordSeparators": " ./\\()\"':,.;<>~!@#$%^&*|+=[]{}~?│，。、；：？！（）“”‘’　〈〉《》「」『』【】·—…～"
```

(Note: the default word separator list is ASCII-only, so the setting above is required to trigger this.)

2. Open a new integrated terminal and type:

```
abc-def（ghi
```

3. Double-click on `abc-def` (the part left of the fullwidth paren).

**Actual:** the selection includes the fullwidth left paren: `abc-def（` (copying and pasting yields `abc-def（`; only the trailing half of the wide glyph may look unhighlighted).
**Expected:** the selection stops at the separator and is exactly `abc-def`.

## Additional observations

- Same repro with an ASCII separator (`abc-def(ghi`) selects `abc-def` correctly.
- A wide character on the **left** boundary of the selection (double-click `ghi` in `abc-def（ghi`) selects `ghi` correctly.
- Manually **drag-selecting** exactly `abc-def` is also correct.
- So the overrun only happens when the double-click word-selection **end** lands on the first cell of a double-width CJK separator character — the word-end boundary appears to be computed one cell too far in that case.

## Environment

- VS Code Version: 1.136.1 (stable)
- OS Version: Windows 11 Pro (10.0.26200)
- Terminal: built-in integrated terminal (xterm.js based)
- Does this issue occur when all extensions are disabled?: Not explicitly tested, but no extensions participate in the repro (built-in terminal + a user setting only)

## Possible relation

- #318709 (Terminal local file links are mis-tokenized around CJK punctuation) — same area (word/token classification around CJK punctuation in the terminal) but a different symptom; filing separately since the repro and code path differ.

The defect may ultimately live in the bundled xterm.js (word-selection end computation next to double-width cells) rather than in VS Code itself; happy to move/relate the report if maintainers prefer.