tree-sitter PowerShell grammar cannot parse ~8% of realistic agent commands, blocking auto-approve suggestions

Follow up to #328052, #328108, #328109.

## Problem

The `tree-sitter-powershell` grammar shipped in `@vscode/tree-sitter-wasm` fails to parse a meaningful fraction of the command lines agents actually emit. Since both the workbench and the Agent Host derive auto-approval from the parse, an unparsable command line means **no auto-approval and no way for the user to fix it from the confirmation UI**.

## Measurement

36 plausible agent-emitted commands parsed with the PowerShell grammar; 3 produced `hasError`:

```
ERROR npm run test -- --grep "foo"
ERROR ./scripts/test.sh
ERROR git diff -- src/
```

That is ~8%. Two distinct triggers, both very common:

1. a bare `--` separator (`npm run test -- …`, `git diff -- `)
2. `./path` at command position (`./scripts/test.sh`, `./gradlew build`)

A third known limitation is already worked around in both codebases: POSIX-style `--flag=value` arguments parse as assignment expressions and truncate the surrounding command (microsoft/vscode#294010), which both `TreeSitterCommandParser` and the Agent Host's `CommandAutoApprover` mask before parsing.

## Impact

With the errored-parse gate in place (#328108, and already shipping in the Agent Host), these command lines resolve to `noMatch` with `autoApproveRuleResolvable: false`. The renderer only offers persistent auto-approve actions when `autoApproveRuleResolvable` is set (`chatTerminalToolConfirmationSubPart.ts`), so the user sees a confirmation with **no auto-approve options at all**, every time, forever.

Honouring explicit `matchCommandLine` rules before parsing (#328109) gives users an escape hatch but does not remove the underlying gap — the suggested sub-command rules still cannot be generated.

## Possible directions

1. Fix upstream in the tree-sitter PowerShell grammar (the `--` and `./path` cases) and pick up the updated wasm.
2. Extend the existing masking workaround to cover a bare `--` separator, in the same spirit as the `--flag=value` mask.
3. Fall back to a coarser tokenizer for suggestion generation only (never for enforcement) so the confirmation can still offer a sensible sub-command rule.

Option 2 is the cheapest and matches an existing precedent; option 1 is the real fix.