security: WARN verdict takes no defensive action

## Summary

When the ML prompt injection ensemble returns a `WARN` verdict (confidence >= 0.60 but below BLOCK threshold), the system logs the event but takes **no defensive action**. The agent continues executing with full tool access as if the scan returned `safe`.

## Current behavior

In `preSpawnSecurityCheck` (`sidebar-agent.ts`):

```typescript
const result = combineVerdict(signals);
if (result.verdict !== 'block') return false; // WARN falls through here
```

WARN is treated identically to safe — no user confirmation, no tool restriction, no rate limiting. The only trace is a log line and a shield icon update.

## Risk

A prompt injection payload that scores just below the BLOCK threshold (e.g., 0.70 confidence from one classifier, not cross-confirmed by the second) gets logged but otherwise runs unrestricted. The ML stack correctly identified it as suspicious, but the system discards that signal.

## Possible mitigations (not prescriptive)

- **User confirmation gate**: show the WARN in the sidepanel, require explicit "proceed anyway" before spawning
- **Tool restriction**: spawn the agent with a reduced allowlist (e.g., Read-only, no Bash/Write) on WARN
- **Rate limiting**: throttle WARN sessions to prevent automated probing
- **Elevated logging**: capture full payload hash + domain for WARN events (currently only BLOCK gets `logAttempt`)

Each has different UX tradeoffs — filing as issue for design discussion rather than prescribing a fix.

## Severity

HIGH — the ML stack has a detection tier (WARN) that produces no defensive output.

Start in sidebar-agent.ts at preSpawnSecurityCheck and trace combineVerdict through the existing BLOCK handling. Review how WARN currently falls through, then resolve which defensive behavior is selected; done means WARN no longer proceeds with unrestricted tool access and the chosen behavior is covered by the project’s relevant checks.

Written by the indexing model from the issue text.