fix(shell): preserve lenient tokenization in chain segments

[esengine]

Follow-up to #233. Fixes the regression flagged in the PR description.

Problem

#233 used shell-quote for chain segmentation. shell-quote follows POSIX strictly, so it tokenizes cargo run -- --flag=1&2 as three tokens with & flagged as a background operator and rejects the call. Pre-#233, tokenizeCommand (lenient by design) treated --flag=1&2 as one literal argv.

That leniency is a deliberate, long-standing choice in this codebase — see the existing detectShellOperator test that documents it explicitly. shell-quote pulls in the opposite direction; mixing the two means fighting one with the other.

Fix

Drop shell-quote entirely. Replace the chain splitter with splitOnChainOps (~50 lines): a whitespace-bounded walker that mirrors detectShellOperator's convention — a chain operator only counts when it begins a whitespace-separated token. Each segment then runs through the existing tokenizeCommand (lenient) and detectShellOperator (rejects >, <, &, 2>&1, &>).

This way the chain layer is consistent with the rest of src/tools/shell.ts: same primitives, same lenient philosophy, same UX for model output that isn't perfectly POSIX.

What recovers

cargo run -- --flag=1&2                      # runs (was rejected post-#233)
git status ; cargo run -- --flag=1&2         # chain runs, second segment keeps &
grep a|b file                                # runs as one segment with regex `a|b`
echo a;b                                     # runs as `echo a;b` (no chain)

What changes

• git status|grep main (no spaces around |) is no longer treated as a chain. It was a shell-quote-only side effect — never worked pre-feat(shell): support |, &&, ||, ; chain operators in run_command #233. Aligns the chain detector with detectShellOperator.
• $VAR and $(…) are no longer rejected. They pass through as literal argv (since we don't invoke a shell). Same as the existing single-command tokenizer's behavior. Models see $HOME in echo's output and learn.

Why not "keep shell-quote + post-process"

The post-process layer would need to walk the original string, find each operator's position, check whether it's at a whitespace boundary, and re-glue tokens that aren't. That's ~30 lines of fight-the-library code on top of the library, with more edge cases than just doing the splitting ourselves. The hand-rolled splitOnChainOps is the same complexity tier as the existing tokenizeCommand (also hand-rolled) and consistent with the project's lenient philosophy.

Tests

• New parser tests: does NOT split on chain chars embedded inside larger tokens, allows embedded chain chars inside chain segments, rejects redirects/background discovered inside a chain segment, rejects empty middle segments, rejects unclosed quotes inside a chain segment.
• Removed: shell-quote-only $VAR and $(…) rejection tests.
• 105 shell-related tests pass; 2197 total.