fix: trim replacements longer than the range they replace

[sarathfrancis90]

Trimming a chunk that was overwritten with a replacement longer than the range it covers corrupts that chunk's bounds, and the resulting sourcemap points outside the source:

const s = new MagicString('ab')
s.overwrite(0, 1, '   xyz')
s.trimStart()

s.toString()                  // 'xyzb' - correct
s.generateDecodedMap().mappings  // [[[0, 0, -1, NaN], ...]] - source line -1
s.generateMap().mappings         // 'AADA,GACA'

Chunk.trimStart/trimEnd pick the split index off content.length, which is only the chunk's original span while the chunk is unedited. Here the chunk covers [0, 1) but its content is 6 characters, so trimStart splits at 1 - 3 = -2 and leaves chunks [0, -2) and [-2, 1). getLocator then resolves the negative start to line -1, column NaN. trimEnd has the mirror problem — it splits past end, so overwrite(1, 2, 'xyz ') + trimEnd() leaves a [4, 2) chunk and makes slice(0, 2) throw "Cannot use replaced character 2 as slice end anchor".

An edited chunk's content has no positional correspondence to its original range, so splitting it at a content offset isn't meaningful in the first place — both halves end up edited regardless. I made the edited case trim in place instead, and left the unedited path alone since that's where the split actually buys accurate per-character mappings.

The existing edited-chunk trim tests (from #257) still pass unchanged. One deliberate difference: a trimmed replacement now maps to the start of the range it replaces rather than to an offset computed from its own length — e.g. overwrite(0, 6, ' abcd') + trimStart() maps at column 0 instead of column 2. Output strings are identical, and unedited trimming is untouched.

I found this fuzzing random sequences of valid operations and checking the decoded mappings stay in bounds.

Verified with pnpm run lint, pnpm test (221 passing) and pnpm run typecheck.