Feature: Per-tool 'always prompt' override (even with --allow-all)

## Summary

Add a `config.json` setting (e.g., `always_prompt_tools`) that requires explicit user confirmation before a tool's first use in a session, **even when running with `--allow-all` or `--allow-all-tools`**.

This creates a middle ground between "allow" and "deny" — the tool is permitted, but always requires a one-time session consent before first invocation.

## Motivation

Tools like WorkIQ (`ask_work_iq`) access sensitive organizational data — emails, meetings, Teams messages — via Microsoft 365 Copilot. Users may want `--allow-all` for file and shell operations but still require explicit consent before querying workplace data.

Today the only options are:
- **Allow all** — no confirmation for any tool, including sensitive ones
- **Deny specific tools** — blocks them entirely, which is too restrictive
- **Custom instructions** — model-level guidance only; not enforceable and can be skipped

There is no way to say: *"This tool is available, but always ask me before using it the first time."*

## Proposed Solution

A new `always_prompt_tools` array in `~/.copilot/config.json`:

```json
{
"always_prompt_tools": ["ask_work_iq", "workiq-ask_work_iq"]
}
```

### Behavior

- Before the first call to a listed tool in a session, Copilot CLI displays a confirmation prompt
- This overrides `--allow-all`, `--allow-all-tools`, and `/allow-all`
- Once the user approves, subsequent calls to that tool in the same session proceed without re-prompting
- If rejected, the tool is blocked for the rest of the session

### Example UX

```
⚠️ WorkIQ (ask_work_iq) wants to access your Microsoft 365 data.
This tool can read emails, meetings, Teams messages, and documents.

Allow for this session? [y/N]
```

## Use Cases

1. **Sensitive data tools** — WorkIQ, M365 integrations, or custom MCP servers that access PII/corporate data
2. **Cost-bearing tools** — Tools that consume API quota or trigger billing (e.g., paid external APIs)
3. **Irreversible actions** — Tools that publish, deploy, or send communications
4. **Compliance** — Organizations requiring audit-friendly consent for data access tools

## Alternatives Considered

- **Custom instructions in `copilot-instructions.md`** — Best-effort only; the model can skip them under heavy context or complex tasks. Not a security boundary.
- **`--deny-tool`** — Too restrictive; blocks the tool entirely rather than gating it behind consent.
- **Per-call confirmation (no `--allow-all`)** — Too noisy; users want frictionless file/shell ops but gated sensitive tools.

## Relation to Existing Issues

This complements the permission system improvements in #307 and Epic #316. Specifically, it adds a consent tier between "allow" and "deny" that isn't covered by the existing `--allow-tool` / `--deny-tool` flags or the proposed permission profiles.