bug(core): YOLO/AUTO_EDIT skips redirection downgrade, auto-allows obfuscated shell (policy-engine.ts)

## What happened?

`packages/core/src/policy/policy-engine.ts:344-351` never downgrades `ALLOW` to `ASK_USER` on shell redirection in YOLO/AUTO_EDIT:

```ts
// Do not downgrade (do not ask user) if in AUTO_EDIT or YOLO mode.
if (
this.approvalMode === ApprovalMode.AUTO_EDIT ||
this.approvalMode === ApprovalMode.YOLO
) {
return false;
}
```

Obfuscated `cmd > /etc/...` or parser-breaking payloads auto-`ALLOW` in YOLO even when `hasRedirection()` is true.

## What did you expect to happen?

Always downgrade `ALLOW→ASK_USER` when `hasRedirection()` is true, even in YOLO, unless an explicit `allowRedirection` opt-in is set. Unparseable shell should default to `ASK_USER`/`DENY`, not `ALLOW`.

## Client information

- Repo `google-gemini/gemini-cli` @ `main` `9c1b0a610`
- Area `packages/core/src/policy/policy-engine.ts:337-354,470-490`
- Platform: source checkout

## Login information

N/A — policy unit test with `approvalMode=YOLO`, `command="echo x > /outside/ws"`.

## Anything else we need to know?

Fix direction: check `hasRedirection()` before the YOLO early-return; add tests for redirected + unparseable commands in YOLO/AUTO_EDIT. Complements #29250 prompt-injection hardening.

Start in packages/core/src/policy/policy-engine.ts at lines 337-354 and 470-490, then inspect the existing policy unit tests. Run the YOLO and AUTO_EDIT policy tests for redirected commands, and add coverage for redirected and unparseable commands. Done means redirection no longer bypasses ASK_USER unless the explicit allowRedirection opt-in is set, and unparseable shell does not default to ALLOW.

Written by the indexing model from the issue text.