fix(core): keep both cwds when one quote reading alone ends a cd - #12363

…-quote-backslash-split

The previous commit suppressed the backslash escape for the whole of an open
single-quoted string. That is right for a plain string, where a backslash is
an ordinary character, but wrong for bash's ANSI-C form: inside $'…' the
backslash does escape, including before the closing quote, so $'a\'' is a
complete word and an operator after it still separates two commands. Reading
it as plain swallowed the real closing quote and glued the line back into one
segment — the same fail-open the previous commit closed, reached from the
other side, and a regression against the merge base rather than a gap it
merely left open.

The scanner now records which form opened the string and suppresses the
escape only for the plain one. A `$` opens the ANSI-C form only when it is
itself unquoted, unescaped and not already spent as the second half of `$$`,
so `\$'a\'`, `$$'a\'` and `"$"'a\'` stay plain, as bash reads them; treating
those as ANSI-C would reintroduce the original bypass through a different
door.

Eight cases pin the behaviour across the three directions, each verified
against `bash -x` as the oracle and each red under the corresponding mutant.

…-quote-backslash-split

The differential run against bash turned up shapes the existing cases do not
reach: a plain and an ANSI-C string side by side in either order, `$$$'…'`
where the PID expansion is followed by a real ANSI-C string, and `$'\''`
whose entire body is an escaped quote. bash runs each of these as two
commands; three of the four go red when the escape is suppressed for every
single-quoted string, so they pin the same guard the ANSI-C cases do from a
different direction.

No production change — the split already handled all four.

…-quote-backslash-split

A `$` separated from its opening quote by a backslash-newline lost its
pending state, so `$\<newline>'a\''` was read as a plain `'…'` string.
The plain reading then swallowed the real closing quote and held the
scanner inside the string to the end of input, returning one segment for
a line bash runs as two commands — the bypass the surrounding exception
exists to close, re-entered through a continuation.

bash removes a backslash-newline before it decides what `$'` means, so
treat the pair as elided and carry the pending `$` across it. The newline
is consumed with the backslash because `'\n'` is itself a command
separator here; leaving it to the `escaped` flag would split every
`echo a\<newline>b` continuation instead.

Also cover the separators and shapes the earlier cases did not reach: a
bare `&` and a newline as the separator for both quote forms, the line
continuation that must not split, and the re-opened quote
`echo 'a\'' ; rm x'`, which bash runs as a single command and which the
corrected scanner keeps in one segment.

…-quote-backslash-split

Two comments stated the mechanism wrongly, in the direction that invites
someone to undo the fix.

The line-continuation branch was justified by `'\n'` being a command
separator, as though leaving the pair to the `escaped` flag would split
the line. It would not: the `escaped` check precedes the operator loop,
so that route consumes the newline too, and deleting the branch keeps
`echo a\<newline>b` whole. What the branch is actually for is the
top-of-loop `dollarPending` reset, which the `escaped` route runs through
and which drops the pending `$`.

The ANSI-C comment put the closing quote one position early: `$'a\''`
holds three quotes and closes at the third, the second being the escaped
one that belongs to the string. Read literally, the old wording is the
blanket-escape reading that glues the line back into one segment.

Also pin the even backslash run. The introducer rule turns on the parity
of the run before the `$` — `\$'` is a plain string, `\\$'` is ANSI-C —
and only the odd side was covered, so a refactor reading an even run as
escaping the `$` would reopen the bypass with the suite green.

…-quote-backslash-split

…-quote-backslash-split

…litting

The plain-quote rule reads a backslash inside '…' as literal, which is
right for a real quoted string but wrong in the regions this scanner does
not model: a # comment, a backtick body and a heredoc body, where bash does
not read the quote characters as quotes at all. There `'a\''` closed at its
second quote, re-opened a string at the third and swallowed the next
command into an allow-covered segment, so `echo done # note 'a\''` followed
by a newline and `rm -rf x` was auto-approved where main asked, and an
explicit deny rule was never reached.

Scan the input under both readings and split wherever either finds an
operator, so the plain-quote fix never removes a boundary the scanner found
before it. Pin the three carriers, and put the plain `'c\'` first in the
ANSI-C, even-run and continuation rows so only bash's reading can split
them and the coarse `!inSingle` guard still turns them red.

Fold the per-case splitter tests and the per-carrier PermissionManager
tests into it.each tables and shorten the explanatory comments. Coverage
is unchanged: every guard mutation still turns at least one case red.

The two backslash readings can only differ at a backslash, so a command
without one needs a single scan. Restores main's timing for backslash-free
input; commands containing a backslash still pay ~2x.

Also pin the terminator the merge loop reports, and restore the ANSI-C
rows that keep the coarse `!inSingle` guard above single digits (11 red).

…-quote-backslash-split

String.trim() also strips \r, \v, \f and \u00a0, which bash treats as
ordinary word characters, so trimming a segment deleted a redirection
target such as `echo x >\u00a0` and the virtual write op vanished from a
verdict that was a deny. Use the same BASH_WORD_SEPARATORS pair QwenLM#11865
adds, dropping a \r only as the first half of a CRLF.

Also pin the boundary sort, which no case covered, and move the
terminator case under describe('splitCompoundCommandSegments').

…-quote-backslash-split

…-quote-backslash-split

Resolve the conflict with QwenLM#11865 in favour of the two-scan split, and move
its CR_IS_WHOLE_REDIRECT_TARGET carve-out into the merge loop so a `\r` that
is the whole redirect target still survives a `\n` terminator. Drop this
branch's copy of the trim tests that QwenLM#11865's rows now cover, keeping only the
last-segment trim case.

…-quote-backslash-split

QwenLM#12096 pinned three `echo 'a\' # …` rows as `allow` and marked them to flip
when this branch lands: the splitter now closes `'a\'` as bash does and splits
at the operator inside the comment, so they resolve to `ask`.

A `$` opens ANSI-C only when the quote follows it directly. Without the
per-character reset, `echo $x'a\' ; touch /tmp/x` collapsed into one segment
and the suite stayed green. Also point the stale "last row" comment at the row
it describes.

bash runs one command in `git commit -m 'x' # saved to 'C:\'⏎rm draft`, but
the pre-fix reading splits inside the comment and a `Bash(rm *)` deny refuses
it. Pin that, the `monitor` spelling, and the single-line spelling QwenLM#12096's
comment fast path allows again.

…-quote-backslash-split

A boundary only one backslash reading finds is split on either way, so a
command is never hidden, but it is not evidence of what bash ran. Reading
such a terminator as `&` (or as foreground) decides on its own whether a
`cd` moved the shell, and a following relative write is then attributed to
a directory bash never entered — `Write(...)` deny rules miss it (QwenLM#12246).

Flag those boundaries in the splitter and, when one ends a `cd`, carry both
the moved and the unmoved cwd through the rest of the walk, emitting the
following operations under each. The permission layer aggregates to the most
restrictive verdict, so the deny holds whichever way bash read the quotes.

…inator-cwd