fix(core): handle simple Bash comments in permission rules - #12096

…-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`.

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.

…ek opt-out

The upgrade-risk section certified that v0.24.1...v0.24.2 held only 8
files / 6 PRs and that #10410 was the sole default-behaviour change.
Re-derived from the tag range: 15 non-test files under
packages/core/src/{tools,permissions}; three commits flip defaults —
#10410 (deferral), #12096 (Bash comment permission verdicts, ungated),
#12198 (undecided-workspace trust gating) — so the section now lists
all three, gains risk rows for the two ungated flips, scopes the
one-line rollback to deferral only, and notes at the re-baseline table
that #12119 changed the /context derivation in the same release.

Also extend the §0.1 status table to §6/§7: §6 row 7's DeepSeek
automatic ToolSearch opt-out was deleted by #10410 (the only remaining
kill-switch is the explicit tools.toolSearch.enabled: false at
config.ts:2102-2114), §7 item 3 is closed now that #10410 shipped, and
the plan doc's twin DeepSeek claim is corrected in the same pass.

Co-authored-by: Qwen-Coder <[email protected]>
Patrol-Run: qwen-pr-closeout/jmuakc4l1ae

My first version certified that "only #10410 changed default behaviour" in
`v0.24.1...v0.24.2` and put that under a heading saying it is the only thing to
worry about. Review found three counterexamples in the range and I confirmed all
three:

- **#12096** (`9036855d`) adds `splitCommandForRules` at four evaluation sites in
  `permission-manager.ts` (+103/−5), gated only on tool name and whether the
  command contains a newline — no setting, no env. A comment-bearing command can
  flip deny→ask, or deny→allow under a broad `Bash(echo *)` rule. Nothing about
  deferral surfaces or undoes that, so the section as written would have sent an
  operator down a toolSearch-only ladder for a permission change.
- **#12198** (`c9839a94`) flips `isTrustedFolder()`'s undecided default.
- **#12034** (`4f027777`) added `MEMORY_CONTEXT_WARNING_MAX_TOKENS`, itself a
  default, which the sibling plan-doc row already records as live.

The "8 files / 6 PRs" count did not reproduce under any filter either, and the
list of six named two PRs that touch neither path. Re-derived from the tag range
with the filter stated: 53 commits, three touching non-test files under
`packages/core/src/{tools,permissions}/`, and a separate table for "changed a
default", which is the wider set the section actually needed. The claim is
narrowed to what is true — the *token*-relevant default change is #10410 — and a
risk row for #12096 is added whose detection step is re-testing existing
`Bash(...)` deny rules against comment-bearing commands, with a note that the
one-line rollback cannot touch it.

§8 item 0 gains the instrument caveat: #12119 shipped in the same release and
rewrote how `/context detail` derives the built-in-tools row, so a pre-upgrade
and a post-upgrade reading are not the same ruler. Both runs should record the
whole `/context detail` output rather than one category number.

Claude-Session: https://claude.ai/code/session_01P31kyHJf9VXo8w6h9uZetg

…wo rulers

`0ed2941b` fixed the enumeration this review flagged, including the #12096
permission-verdict row. One half of the same finding is still open: §8 item 0
asks the reader to subtract a pre-upgrade `/context detail` reading from a
post-upgrade one and call the difference #10410's saving, but #12119 shipped in
the same release and rewrote how that row is derived. The two numbers come from
different instruments, so the subtraction silently folds a measurement-method
change into the attribution the item exists to separate.

Asks for the whole `/context detail` output on both runs rather than the one
category number, so the method difference stays recoverable afterwards, and says
what the first row is worth if only a single figure survives.

Claude-Session: https://claude.ai/code/session_01P31kyHJf9VXo8w6h9uZetg

…fix bullets

context-cost.md: the prefix-cache bullet stated prefix stability for deferral
unconditionally. Carry the exception tool-search.ts:133 documents -- a tool-set
refresh may still re-declare a withheld tool when the live history contains a
direct call to it -- without implying the bridge path itself reveals. (R3-7)

context-token-governance README: the #12096 row's detection column audited only
the deny side, which cannot surface the flip's lasting consequence. Rewrite it
to lead with the allow side (re-audit the broad Bash(...) allow rule minted by
an "Always allow" click on a comment-bearing command) and link the in-repo
design doc that records the hazard. (R3-9)

R3-5 is declined on the thread with evidence: no reachable configuration puts a
tools.eager-demoted tool both outside getDeferredToolSummary() and genuinely
unreachable for the session.

Co-authored-by: Qwen-Coder <[email protected]>
Patrol-Run: qwen-pr-closeout/jmubzrz80d3

…ntested (QwenLM#12355)

* fix(core,docs): correct what the deferred-tool bridge made stale or untested

QwenLM#10410 landed (`70edbf47`) and invalidated three claims that are now in main,
two of them mine, plus it exempted a tool from the eager allowlist without a
test.

**An exemption shipped untested.** `isExemptFromEagerAllowList` gained
`tool_call` — necessary, because `tool_search` reviews a withheld schema and
`tool_call` invokes it, so withholding `tool_call` under a narrow allowlist
would leave every demoted tool readable and uncallable. The exemption table in
`permission-manager.test.ts` lists the other seven and not this one, so
deleting that arm of the source left the whole suite green. Added, which also
extends the paired "a whole-tool deny still wins over the exemption" case to it.

**`docs/users/features/context-cost.md` was advising against the new default.**
Its trap said a mid-session reveal invalidates the prompt-cache prefix and that
`threshold: 0` only wins when a session never needs the deferred tools. The
bridge keeps the declared list byte-stable, so discovery no longer rebuilds the
prefix, and `threshold` now defaults to `0` for exactly that reason. Rewritten
to say what the cost actually is — one round trip before first use — and when
raising the threshold buys it back.

Two smaller corrections on the same page: the exempt-family list omitted
`tool_call`, and "it needs `tool_search` to stay on" is now both halves of the
bridge, with the asymmetry that matters spelled out — ordinary deferred tools
fall back to eager declaration when a bridge half is missing, while tools
demoted by `tools.eager` do not. It also gains a baseline note, because an
allowlist's saving is now only the eager-by-default schemas it withholds: the
on-demand pool already left the first request, so a figure measured before
QwenLM#10410 attributes that saving to the wrong lever.

**The plan doc's cost model is void, not pending.** Its section 6 carried a
warning that QwenLM#10410 *would* invalidate the arithmetic; it has, so the note now
says so outright and names what replaced it, and the status row for QwenLM#12029
records that both halves of that issue are settled.

Refs QwenLM#12028, QwenLM#12029

Claude-Session: https://claude.ai/code/session_01P31kyHJf9VXo8w6h9uZetg

* docs(verification): re-baseline the token handoff for v0.24.2

The handoff brief was written on 2026-09-16 against a build where
`tools.toolSearch.threshold` defaulted to `10`, so the deferred pool was
preloaded at session start whenever it fit in 10% of the window — which on a 1M
window it always did. `v0.24.2` ships QwenLM#10410, which makes discovery go through
the `tool_search` → `tool_call` bridge without rewriting the declared list, and
flips that default to `0`. Two of the brief's sections are void as a result: its
measured baseline, and its cost model for demotion.

Adds §0.1, placed before everything else and pointed at from the header:

- what changed and why the on-demand path only now engages by default, which is
  also the honest explanation for part of the "tens of thousands on the first
  turn" the brief was written to attack;
- a section-by-section list of what still holds — the allowlist semantics do,
  with `tool_call` added to the exempt families; the subagent risk does, verified
  today against `agent-core.ts`, which still asks for `includeDeferred: true`;
- the re-baseline procedure, with the version floor that silently invalidates a
  run (0.24.1 and earlier measure the old behaviour), the derived expectation
  stated as derived, and the three things to check when the number does not move;
- a risk table for what `v0.24.2` changes for existing users, with the one
  silent failure mode — the model not thinking to look for a withheld tool — and
  a one-line rollback that restores the old preload.

§8 gains the table that separates the two attributions, because the whole point
of re-measuring is to tell what QwenLM#10410 gave away for free from what an eager
allowlist is worth; measured together, the upstream saving lands on the
deployment's configuration. It also gains the routing-miss question, which has
no automated gate and matters more than any of the token figures.

Refs QwenLM#12028, QwenLM#12333

Claude-Session: https://claude.ai/code/session_01P31kyHJf9VXo8w6h9uZetg

* fix(docs): drop the removed DeepSeek ToolSearch opt-out from context-cost.md

Two clauses still claimed prefix-caching models such as DeepSeek are
automatically opted out of the ToolSearch + ToolCall bridge: the rewritten
bullet on when the bridge ends up unregistered, and the trap-list entry that
ends with "DeepSeek models opt out of ToolSearch automatically for this
reason". That opt-out was removed in QwenLM#10410: packages/cli/src/config/config.ts
gates purely on settings.tools?.toolSearch?.enabled === false and explicitly
keeps the bridge enabled for prefix-cache-sensitive models, and the config
tests assert deepseek models no longer get tool_search/tool_call denied.

Co-authored-by: Qwen-Coder <[email protected]>
Patrol-Run: qwen-pr-closeout/jmu9wrczi92

* docs(users): say the prefix-cache trade no longer inverts for deferral

`3d302b36` removed the false fact — DeepSeek models are no longer opted out of
ToolSearch automatically, since QwenLM#10410 deleted the model-name regex. The
sentence it left behind still carries the false implication: that for a
prefix-caching model, keeping the declaration list identical beats keeping it
small. Reaching a withheld tool is now prefix-stable, so for the deferral
decision there is nothing left to invert, and a deployment that disabled
ToolSearch by hand to protect a prefix is holding a reason that has expired.

Prefix stability still argues against everything else that rewrites the prefix
mid-session, so the bullet keeps that half rather than disappearing.

Claude-Session: https://claude.ai/code/session_01P31kyHJf9VXo8w6h9uZetg

* docs(verification): correct the v0.24.2 change enumeration and DeepSeek opt-out

The upgrade-risk section certified that v0.24.1...v0.24.2 held only 8
files / 6 PRs and that QwenLM#10410 was the sole default-behaviour change.
Re-derived from the tag range: 15 non-test files under
packages/core/src/{tools,permissions}; three commits flip defaults —
QwenLM#10410 (deferral), QwenLM#12096 (Bash comment permission verdicts, ungated),
QwenLM#12198 (undecided-workspace trust gating) — so the section now lists
all three, gains risk rows for the two ungated flips, scopes the
one-line rollback to deferral only, and notes at the re-baseline table
that QwenLM#12119 changed the /context derivation in the same release.

Also extend the §0.1 status table to §6/§7: §6 row 7's DeepSeek
automatic ToolSearch opt-out was deleted by QwenLM#10410 (the only remaining
kill-switch is the explicit tools.toolSearch.enabled: false at
config.ts:2102-2114), §7 item 3 is closed now that QwenLM#10410 shipped, and
the plan doc's twin DeepSeek claim is corrected in the same pass.

Co-authored-by: Qwen-Coder <[email protected]>
Patrol-Run: qwen-pr-closeout/jmuakc4l1ae

* docs(users): align tools.eager bullets with the bridge's real semantics

Three corrections against the repo's own authoritative text
(settingsSchema tool descriptions, the client.ts incomplete-bridge
warning, tool-registry.ts:1055):

- Removal enumeration: dropping a non-exempt tool takes a whole-tool
  permissions.deny rule, a tools.disabled entry, or --exclude-tools
  (not permissions.deny alone); for the bridge pair,
  tools.toolSearch.enabled: false removes both halves at once. Bullet
  4's incomplete-bridge cause list is widened to match the warning.
- A withheld tool with a missing bridge half is not "at no route at
  all": it is not offered to the model and cannot load through the
  bridge, but stays registered and a direct call by name still goes
  through normal approval.
- Removing a bridge half is not equivalent to giving up the allowlist:
  every ordinary deferred tool is force-declared into every request
  while the withheld tools lose their discovery route.
- The threshold advice is scoped to ordinary deferred tools: the
  preload never reveals tools demoted by tools.eager.

Co-authored-by: Qwen-Coder <[email protected]>
Patrol-Run: qwen-pr-closeout/jmuakc4l1ae

* docs(verification): correct the v0.24.2 upgrade-risk triage

My first version certified that "only QwenLM#10410 changed default behaviour" in
`v0.24.1...v0.24.2` and put that under a heading saying it is the only thing to
worry about. Review found three counterexamples in the range and I confirmed all
three:

- **QwenLM#12096** (`9036855d`) adds `splitCommandForRules` at four evaluation sites in
  `permission-manager.ts` (+103/−5), gated only on tool name and whether the
  command contains a newline — no setting, no env. A comment-bearing command can
  flip deny→ask, or deny→allow under a broad `Bash(echo *)` rule. Nothing about
  deferral surfaces or undoes that, so the section as written would have sent an
  operator down a toolSearch-only ladder for a permission change.
- **QwenLM#12198** (`c9839a94`) flips `isTrustedFolder()`'s undecided default.
- **QwenLM#12034** (`4f027777`) added `MEMORY_CONTEXT_WARNING_MAX_TOKENS`, itself a
  default, which the sibling plan-doc row already records as live.

The "8 files / 6 PRs" count did not reproduce under any filter either, and the
list of six named two PRs that touch neither path. Re-derived from the tag range
with the filter stated: 53 commits, three touching non-test files under
`packages/core/src/{tools,permissions}/`, and a separate table for "changed a
default", which is the wider set the section actually needed. The claim is
narrowed to what is true — the *token*-relevant default change is QwenLM#10410 — and a
risk row for QwenLM#12096 is added whose detection step is re-testing existing
`Bash(...)` deny rules against comment-bearing commands, with a note that the
one-line rollback cannot touch it.

§8 item 0 gains the instrument caveat: QwenLM#12119 shipped in the same release and
rewrote how `/context detail` derives the built-in-tools row, so a pre-upgrade
and a post-upgrade reading are not the same ruler. Both runs should record the
whole `/context detail` output rather than one category number.

Claude-Session: https://claude.ai/code/session_01P31kyHJf9VXo8w6h9uZetg

* docs: close the five remaining review findings on this PR

R1-5, R1-6, R1-7, R1-8, R1-9. R1-1/R1-2/R1-3/R1-4 and §7 item 3 were handled in
`0ed2941b`, `57b26d13` and `70c9c3f8`.

**R1-5 — the QwenLM#12029 cell over-closed.** QwenLM#10410 changed a *default*; it added no
cap. `client.ts` still sizes the budget as `floor(window × percent / 100)` with
the percentage clamped to 100 — symmetric in percent, not in tokens — and the
preload stays all-or-nothing. Default `0` only means it does not fire by
default, and this repo's own verification brief tells a reader to raise the
threshold when a session will certainly need those tools, which brings the gap
straight back. Recorded as half-closed, with the reason.

**R1-6 — the plan's §10 table contradicted the sibling README it is cross-linked
to.** QwenLM#12142 was listed as awaiting review after shipping in `v0.24.2`
(`36887c49`), and QwenLM#12030's first half as awaiting review after merging
(`fbd6ccc2`) on an issue closed the same day. Both rows corrected, with the
part that is genuinely not done said plainly: the conditional-rule mechanism
landed, and nobody has moved any content onto it.

**R1-7 — the plan's own baseline had no void banner** while the README marked
its equivalent explicitly. Added at the top, naming which sections the numbers
belong to and pointing at §0.1 for the re-baseline. It also corrects §10's "less
than a tenth of that step" against the 4.2k/11.4k split this PR's own README
states, and notes §3's exemption list needs `tool_call`.

**R1-8 — the exempt-floor figure is stale.** 2,163 counted `task_stop` (which is
`shouldDefer=true` and not resident) and omitted `tool_call` (exempt and
resident since QwenLM#10410), while `tool_search` has drifted 375 → 394. Restated at
~2,230 from the reviewer's probe, attributed to them rather than claimed as
mine, with the reader's own `/context detail` named as the authority.

**R1-9 — item 0 marked the wrong row required.** Row 1 is conditional on an
environment the reader may not still have; row 2 is what §0.1 makes mandatory
and what both subtractions need. Row 2 is now the required one, with the derived
~17,300 named as the fallback when row 1 is unobtainable.

Claude-Session: https://claude.ai/code/session_01P31kyHJf9VXo8w6h9uZetg

* docs: cite the tool-search gate by symbol, fix the v0.24.2 commit-count basis

Three accuracy corrections to text this PR itself added, taken from the
approving review's non-blocking nits.

- `config.ts:2102-2114` named auth-type resolution and
  `validateModelProvidersConfig`; the `tools.toolSearch.enabled === false`
  gate is `shouldDisableToolSearch`. Both files now cite the symbol rather
  than a line range, so the citation cannot drift again.
- §0.1 announced a `packages/core/src/{tools,permissions}` counting basis
  and then listed six commits on a topical one. QwenLM#12198 touches no file
  under either directory and QwenLM#12271/QwenLM#12346 only tests, so the announced
  filter yields three. The two bases are now stated separately.
- `70edbf47` has a single parent, so it is a squash commit, not a merge
  commit.

* docs: replace the staleness banners with the corrections they announced

Every stale claim this PR identified is now corrected in place instead of
being voided by a remote banner that the reader has to have read first.

plan doc:
- §3: the exemption list gains `tool_call`, and the "bridge incomplete"
  fallback row states the real behaviour -- `resolveDeferredToolsForReminder`
  reveals ordinary deferred tools but withholds the `tools.eager`-demoted ones
  (still registered, direct call by name still uses normal approval) and warns
  once -- replacing "急，揭示全部". The exemption bullet now separates
  "exempt" from "resident" and lists the real removal levers.
- §6: the whole-section void notice sits under `## 6. 成本模型`, which is
  where the top banner points; the `threshold: 0` subsection notice defers to
  it instead of contradicting its scope. §4's 盈亏线 reference and §8's
  "≤ 2 次" line carry their own markers.
- §7 item 4 and §3's table cite `revealDeferredToolsReferencedInHistory` by
  symbol instead of the drifted `client.ts:1783-1822` range.
- §10: the retracted "不到这一步的十分之一" sentence is rewritten in place to
  the post-QwenLM#10410 attribution (~4.2k from QwenLM#10410, ~11.4k left to the
  allowlist), keeping the 21,461 -> 4,080-5,766 baseline pair.

verification README:
- §2.6: heading, ¥ table, the ≤2 SLO blockquote and the "QwenLM#10410（open）"
  closing line are all marked or corrected in place, so the section no longer
  contradicts §7 item 3's 已收口.
- §0.1: the "still near 21,461" ladder gains the QwenLM#12119 instrument rung;
  `MEMORY_CONTEXT_WARNING_MAX_TOKENS` is described as the warning threshold it
  actually is (`Math.min(ratioTokens, MAX)`, nothing truncates memoryContent)
  rather than a cap on loaded context, matching the plan doc, and the new
  post-upgrade warning gets its own risk-table row; the QwenLM#12198 flip is scoped
  to `security.folderTrust.enabled`, which defaults false.
- §2.1: "exempt" and "resident" are split, so `task_stop` / `mcp__*` /
  `computer_use__*` are no longer described as resident, while `task_stop`
  stays on the exemption list with the reason denying it is unsafe.
- §8 item 0: one attribution rule with explicit precedence -- row3-row2 is the
  reliable one, row2-row1 only when row 1 is a real measurement, and ~17,300
  is a row-2 expectation rather than a row-1 substitute. Item 1's direction is
  corrected: both §2.5 projections are floor + allowlisted schemas with no
  on-demand-pool component, and the floor rose 2,163 -> 2,230, so they read
  about 67 higher on >= 0.24.2, not lower.

Co-authored-by: Qwen-Coder <[email protected]>
Patrol-Run: qwen-pr-closeout/jmubr7c3ecn

* docs: close out the three deferred findings on the risk table and prefix bullets

context-cost.md: the prefix-cache bullet stated prefix stability for deferral
unconditionally. Carry the exception tool-search.ts:133 documents -- a tool-set
refresh may still re-declare a withheld tool when the live history contains a
direct call to it -- without implying the bridge path itself reveals. (R3-7)

context-token-governance README: the QwenLM#12096 row's detection column audited only
the deny side, which cannot surface the flip's lasting consequence. Rewrite it
to lead with the allow side (re-audit the broad Bash(...) allow rule minted by
an "Always allow" click on a comment-bearing command) and link the in-repo
design doc that records the hazard. (R3-9)

R3-5 is declined on the thread with evidence: no reachable configuration puts a
tools.eager-demoted tool both outside getDeferredToolSummary() and genuinely
unreachable for the session.

Co-authored-by: Qwen-Coder <[email protected]>
Patrol-Run: qwen-pr-closeout/jmubzrz80d3

* docs: correct the allowlist-reading direction and four stale claims

Applies the doc-accuracy findings two independent verifiers raised at
1b956a8 (wenshao's local real-environment run and the /triage sandbox
round). Every one of them is in text this PR writes; no production code
is touched.

- README §2.5 and §8 item 1 predicted the /context allowlist reading
  would go up by ~67 on >= 0.24.2. Measured in the real TUI it goes down
  681 for the aggressive list (~-0.8k for the conservative one), because
  an allowlist entry admits its whole family (toolMatchesRuleToolName):
  read_file brings zoom_image, run_shell_command brings monitor, and both
  are on-demand tools that v0.24.1's threshold-10 preload declared. The
  +67 floor term stays, now labelled as one of two opposing forces; the
  two sentences asserting the direction are removed. §2.1's correction
  also notes that "本来就不常驻" holds on >= 0.24.2 but not for the
  v0.24.1 reading it corrects.
- README §0.1 MCP row and context-cost.md: the preload runs at session
  start and MCP servers usually connect after it, so a fresh launch
  declares no MCP tools at any threshold (v0.24.1 measured 0/8).
- permission-manager.test.ts: the tool_call comment claimed withholding
  it would leave every demoted tool readable and uncallable. Both bridge
  halves are alwaysLoad=true, so the declaration list does not move
  without this arm; what it protects is the permission-deferred state
  other readers consult (speculation, workflow-authoring skill). The test
  row itself is unchanged.
- QwenLM#12032 rows: 1,104 characters / ~276 tokens is already stale on the
  main this PR merges into (prompts.test.ts there pins 1,421 / ~355), so
  both rows are corrected here instead of deferred.
- Plan doc §3 table: four re-emitted line ranges no longer point at what
  they name (permission-manager.ts:848-866 now lands on
  isExemptFromEagerAllowList itself), so they are cited by symbol, per the
  convention the same table already uses for its other rows.

Co-authored-by: Qwen-Coder <[email protected]>
Patrol-Run: qwen-pr-closeout/jmucrn2bbei

---------

Co-authored-by: yiliang114 <[email protected]>
Co-authored-by: Qwen-Coder <[email protected]>

…tting (QwenLM#11765)

* fix(core): read a backslash inside single quotes as literal when splitting

A backslash is an ordinary character inside single quotes in bash, so a
command ending in one closes its string and an operator after it separates
two real commands. The compound-command splitter read that backslash as an
escape, consumed the closing quote, and stayed inside the quote to the end
of the input, returning the whole line as a single segment.

Permission rules are matched per segment, so the carrier command's allow
rule then covered whatever followed the operator: with only Bash(echo *)
allowed, `echo 'a\' ; rm -rf x` was auto-approved and the rm ran with no
prompt. An explicit deny rule was lost the same way, because the command it
names never became a segment to match against.

The escape now applies outside quotes and inside double quotes only, which
is what bash does.

* fix(core): keep the escape inside bash's ANSI-C quotes when splitting

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.

* test(core): cover mixed quote forms on one line when splitting commands

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.

* fix(core): elide a line continuation before deciding the quote form

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.

* docs(core): correct why the continuation branch and ANSI-C quoting work

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.

* fix(core): keep every boundary either backslash reading finds when splitting

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.

* refactor(core): condense splitter comments and quote-handling tests

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.

* perf(core): skip the second scan when the command has no backslash

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).

* fix(core): trim only the whitespace bash's lexer discards when splitting

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').

* test(core): pin the one-character reach of a pending `$`

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.

* test(core): pin the false deny this split declares as its tradeoff

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.