CLI: expose working directory (--cwd) and a read-only tool mode for filesystem-capable adapters

## Context

While scaffolding the `airframe` CLI (and a GitHub Action on top of it), we worked through how the agentic adapters reference checked-out source code. Two gaps surfaced that stand between "runs an agent" and "safely reviews a repo in CI."

The filesystem-capable adapters are the agentic SDK ones — **claude**, **github-copilot**, **kimi** (and **opencode** server, which isn't usable in a stateless runner). The HTTP/gateway adapters (opencode-zen/-go, openrouter, bedrock) have no file tools and only see the prompt.

Today, those agentic adapters root their file tools at the **inherited process cwd**:
- `ClaudeOptions` has no `working_directory` field at all — the Claude SDK subprocess simply inherits the `airframe` process cwd.
- `CopilotOptions` / `KimiOptions` expose `working_directory`, but default to the process cwd.

So "point the agent at the repo" currently means "cd to the repo before running" — there's no explicit knob on the CLI, and no pass-through for provider options.

## Gap 1 — `--cwd` flag on the CLI

`airframe run` calls `execute()` with no working-directory control. Add a `--cwd PATH` flag so the agent's filesystem root is explicit rather than implicit (and so callers don't have to manipulate the shell's cwd). It should map to:
- Claude: run the SDK subprocess from that directory (chdir / SDK cwd).
- Copilot / Kimi: their `working_directory` provider option.
- HTTP adapters: no-op (or a clear note that they don't read the filesystem).

## Gap 2 — read-only tool mode

The Claude adapter sets `permission_mode="bypassPermissions"` and never sets `disallowed_tools`. Per the Claude Agent SDK docs, `allowed_tools` does **not** constrain `bypassPermissions` — so the agent can `Write`, `Edit`, and run arbitrary `Bash`, not just read.

On a `pull_request` trigger, the diff / issue text is attacker-influenceable, so prompt-injection → `Bash`/`Write` is a real blast radius for a "security review" use case. There is currently **no read-only / tool-restriction surface** on the protocol or the CLI.

Add a way to request read-only (no write/exec) tool access:
- Claude: `disallowed_tools=["Bash", "Write", "Edit"]` (and friends).
- Copilot / Kimi: their equivalent tool-restriction surface.
- Decide whether this is a CLI flag (e.g. `--tools read-only|full|none`), a protocol/session concept, or both.

## Acceptance sketch

- [ ] `airframe run --cwd ` roots filesystem-capable adapters at ``.
- [ ] A read-only mode that prevents write/exec tools on claude (and copilot/kimi where supported).
- [ ] Clear behavior/docs for adapters that don't read the filesystem.
- [ ] Conformance coverage where it makes sense.

## Notes

- This is the "phase 2 tool access" follow-up to the CLI work (`feat/cli-entrypoint`) and the GitHub Action scaffold under `action/`.
- Relates to the broader question of whether/how to expose GitHub MCP tools per-adapter (MCP is provider-gated; the gateways decline it).

Trace `airframe run` into `execute()` and inspect `ClaudeOptions`, `CopilotOptions`, and `KimiOptions`, along with the CLI and `action/` scaffold mentioned in the issue. Define how `--cwd` and read-only access flow through filesystem-capable adapters, document HTTP-adapter behavior, and add conformance coverage where applicable.

Written by the indexing model from the issue text.