feat: three-mode safety policy with decoupled classifier

[trungutt]

Why

Shell command approval today is a coarse two-mode toggle:

• safer on a shell toolset: the classifier asks about anything
  it doesn't positively recognise as safe.
• safer off (or --yolo): everything auto-approves.

That's it. There's no way to say "I trust you on read-only calls,
but ask me before you destroy something". A user who finds strict
mode annoying has only one escape hatch — full auto-approve — and
loses the safety net for genuinely destructive commands.

The classifier itself is also entangled with the approval verdict.
It reads the session's safety policy, decides whether to ask, and
emits its verdict directly. That makes it impossible to reuse the
classifier's judgement anywhere else (UI badges, telemetry, other
gating logic) without duplicating its rules, and adding a new
approval mode means editing the classifier.

What this PR does

Introduce three explicit safety modes and split the classifier
into a pure labeller so the mode is what actually gates the call.

                     ┌─────────┬─────────────┬─────────┐
                     │  safe   │ destructive │ unknown │
        ┌────────────┼─────────┼─────────────┼─────────┤
        │ Strict     │   ASK   │     ASK     │   ASK   │
        │ Balanced   │  ALLOW  │     ASK     │   ASK   │
        │ Autonomous │  ALLOW  │    ALLOW    │  ALLOW  │
        └────────────┴─────────┴─────────────┴─────────┘

• Strict — today's default. Prompt on every tool call.
• Balanced — new middle tier. The read-only path (ls, git status,
  docker ps, …) flows through silently; destructive and unrecognised
  calls still prompt.
• Autonomous — legacy yolo. Auto-approve everything.

Custom Allow/Ask/Deny rules layer on top and always win over the
mode. A distinction the runtime enforces: a rule the user added at
runtime (session-scoped) beats even Autonomous, while a rule the
agent author baked into the YAML is advisory and yields to
Autonomous.

The classifier that used to make the verdict now only labels the
call. Downstream (the runtime, hosting applications, telemetry) all
see the same three values — safe / destructive / unknown — and
each layer decides what to do with them independently.

                      ┌────────────────────┐        ┌────────────────────┐
   shell call    ───▶ │  safer_shell hook  │ ─────▶ │  mode × label      │ ─▶ allow / ask
                      │  (label only)      │ label  │  decision table    │
                      └────────────────────┘        └────────────────────┘
                        safe / destructive           reads session mode
                        / unknown

Notes for the reviewer

• The safer: true opt-in on shell toolsets is removed from the
  schema. Any agent that declares a shell toolset gets the
  classifier automatically — it never blocks, only labels.
• Resume verbs the CLI/API can send back grow two entries so the
  confirmation UI can offer "approve + switch to Balanced" and
  "approve + switch to Autonomous" alongside the existing single-call
  approve.
• No behavioural change for existing --yolo users: yolo maps to
  Autonomous and every call still auto-approves.
• Strict is unchanged from today's no-yolo default — every call
  prompts. The only new behaviour is Balanced.

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

This PR cleanly implements the three-mode safety policy (Strict/Balanced/Autonomous) with a well-designed decoupled classifier. The core logic in pkg/runtime/toolexec/permissions.go is correct: the mode × label decision table, the session-vs-team ForceAsk precedence, and the legacy ToolsApproved sync are all sound.

One confirmed gap: the new Balanced mode is wired in the full TUI but is missing from the leantui keyboard handler — see the inline comment below.

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

This PR is well-structured: the three-mode safety architecture (Strict / Balanced / Autonomous), the decoupled classifier labeller, and the custom rule precedence model (session ForceAsk beats mode; team ForceAsk is advisory and yields to Autonomous) are all implemented correctly. One functional gap was found in the CLI interaction path.