fix: keep position: 'middle' within the column budget

[spokodev]

With position: 'middle', the budget is split with Math.floor(columns / 2) without reserving room for the truncation character. When the character does not fit in the remaining space (most visibly with space: true, where it becomes …, width 3), the right slice clamps to empty while the left slice plus the character already exceed columns:

cliTruncate('unicorns', 2, {position: 'middle', space: true}); // 'u … '  width 4 (budget 2)
cliTruncate('unicorns', 3, {position: 'middle', space: true}); // 'u … '  width 4 (budget 3)
cliTruncate('unicorns', 4, {position: 'middle', space: true}); // 'un … ' width 5 (budget 4)

This breaks the documented invariant that the result occupies at most columns columns (position: 'end'/'start' stay within budget at the same widths).

The fix caps the left slice at columns - truncationWidth, so the two slices plus the truncation character never exceed columns, and drops the padding spaces when the padded character itself would not fit (so some text can still be shown). Normal widths are unchanged — columns: 7 still yields uni … s. Verified width <= columns across ASCII and wide-character text for every position and space setting (264 combinations); existing wide-char test (issue #28) still passes. Added regression assertions.

[sindresorhus]

I found one case this still misses: the new width reservation does not cover the preferTruncationOnSpace branch. With position: 'middle', space: true, and preferTruncationOnSpace: true, the result can still exceed columns:

cliTruncate('unicorns', 4, {position: 'middle', space: true, preferTruncationOnSpace: true});
//=> 'u … ns' // width 6, budget 4

That branch still seems to use a hard-coded + 1 when finding the right slice, so it should use the actual truncation width too. Please add a regresion test for this option combo.

[spokodev]

Good catch, thanks. Fixed: the prefer-on-space middle branch now reserves the actual truncationWidth for the right-hand break point instead of the hard-coded + 1, so cliTruncate('unicorns', 4, {position: 'middle', space: true, preferTruncationOnSpace: true}) is now 'u … ' (width 4). getIndexOfNearestSpace only searches rightward here, so it can only shorten the slice, never push it past the budget. Added a regression test for the middle + space + preferTruncationOnSpace combo (including a width-<= loop over small columns).