Sentences containing the word kill in a heredoc body are misinterpreted as kill commands

### Describe the bug

## Description

The GitHub Copilot CLI's shell-command interception filter reads `bash`-tool heredoc-body data as if it were shell syntax. A heredoc body containing ordinary text such as `kill`, `pkill`, or `killall` is therefore rejected as a malformed `kill` command when that text is stdin payload for another program rather than shell command syntax.

In the tested heredoc cases, the trigger fires even when `kill` appears mid-line, after leading whitespace, or alone on its own line.

This report focuses on heredoc-body scanning specifically. In the non-heredoc forms tested, the filter passed literal text containing `kill` in single-quoted arguments, double-quoted arguments, `$'...'` ANSI-C strings, and a simple quoted-assignment-plus-expansion case. The rejection appears only for heredoc bodies, both `<<'DELIM'` quoted and `< or kill -9
```

The heredoc-body check is stricter than the quoted-argument check. `echo "kill"` passes, but a heredoc body containing only `kill` is rejected. This asymmetry suggests that heredoc bodies and ordinary quoted bash arguments are evaluated under different interception conditions.

### Tested non-heredoc forms that the filter passes

| Form | Passes? |
|---|---|
| `echo 'kill the lights before bed'` | yes |
| `echo "kill the lights before bed"` | yes |
| `echo "kill"` | yes |
| `printf '%s\n' "kill the lights before bed"` | yes |
| `x="kill the lights before bed"; echo "$x"` | yes |
| `printf $'kill the lights\nbefore bed\n'` | yes |

### Heredoc-body behavior

| Heredoc body text | Result |
|---|---|
| `kill the lights before bed` | rejected |
| `pre kill the lights before bed` | rejected |
| ` kill the lights before bed` | rejected |
| `kill` | rejected |
| `pkill the lights` | rejected with the analogous `pkill` interception message |
| `the lights got killed` | passes |
| `just-kill-something` | passes |

These tests show that the filter passes several common non-heredoc quoting/data contexts — single quotes, double quotes, ANSI-C quoting, and a simple quoted-assignment-plus-expansion case — while rejecting comparable text in heredoc bodies. The heredoc trigger appears to respect whole-word boundaries.

For unquoted heredocs, bash can still perform expansions inside the body. For example, command substitution such as `$(kill foo)` would be executable syntax and may legitimately need scrutiny. The observation in this report is narrower: ordinary heredoc text without an expansion is being rejected as though it were shell command syntax.

I have not exhaustively tested every bash construct containing literal text — for example here-strings (`<<<`), process substitution (`<(...)`), command substitution (`$(...)`), or backticks. The claims here are limited to the tested contrast cases above and to the reproducible heredoc rejection.

## Expected Behavior

A heredoc-grammar-aware filter would:

* When encountering a quoted heredoc opener such as `<<'DELIM'`, treat the body through the matching `DELIM` line as literal stdin data and not subject it to command-token interception.
* For unquoted heredocs such as `<

Start by locating the GitHub Copilot CLI shell-command interception filter and reproduce the quoted and unquoted heredoc examples with `kill`, `pkill`, and `killall`. Trace how heredoc delimiters, body text, and expansions are classified; done means ordinary heredoc data is not intercepted while executable expansions remain scrutinized.

Written by the indexing model from the issue text.