[ENHANCEMENT] Add YOLO mode for explicit broad auto-approval #132

Problem (one or two sentences)

Advanced users sometimes want a single explicit mode that lets Zoo proceed through ordinary tool, MCP, and command approval prompts without repeatedly stopping for confirmations. Existing auto-approval settings are granular, but configuring them one by one is tedious for trusted local workflows.

Context (who is affected and when)

This affects users who run Zoo Code in local repositories where they already trust the agent to perform broad actions, such as repetitive code edits, file reads, terminal commands, MCP calls, and subtask/mode operations. It is most useful in private development environments where speed matters and the user intentionally accepts the increased risk.

Desired behavior (conceptual, not technical)

Zoo Code should provide an explicit opt-in YOLO mode. When enabled, Zoo should effectively auto-approve broad tool, MCP, and command categories while still respecting denied command prefixes, still requiring the protected-write setting for protected writes, and still asking real follow-up questions that need user input.

Constraints / preferences (optional)

• YOLO mode must be off by default.
• Do not add confirmation pop-ups, nag screens, or notification surfaces.
• Denied command prefixes remain hard blocks.
• Protected writes remain gated unless protected-write auto-approval is separately enabled.
• Follow-up suggestions should not be silently auto-selected in YOLO mode.
• Settings should continue to use the local cached settings buffer until the user saves.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Zoo Code Task Links (optional)

N/A

Acceptance criteria (optional)

• Given YOLO mode is disabled, existing auto-approval behavior is unchanged.
• Given YOLO mode is enabled, ordinary tool asks, MCP asks, and terminal command asks are approved without extra confirmation unless a deny/protected-write rule applies.
• Given a command matches a denied command prefix, YOLO mode denies it.
• Given a protected write is requested and protected-write auto-approval is not enabled, Zoo still asks.
• Given a follow-up suggestion is shown, YOLO mode does not auto-select it or start the follow-up countdown.
• Individual auto-approval controls are visibly overridden/locked while YOLO mode is active.

Proposed approach (optional)

Add yoloMode to global settings and extension state, teach checkAutoApproval to handle YOLO before the normal granular auto-approval path, update chat/settings UI to show YOLO as active and lock individual controls, and keep SettingsView wired through cachedState.

This issue and the associated PR were prepared with agentic AI assistance, then reviewed by a human. The underlying feature has been tested in production business use for several weeks in the contributor's fork.

Trade-offs / risks (optional)

This intentionally broadens auto-approval for users who enable it. The main review concern is whether the remaining guardrails are sufficient and whether the UI text makes the risk clear without becoming a nag surface.

Related but not duplicate issues:

• [ENHANCEMENT] Reduce approval-control flash for auto-approved read-only asks #102
• [ENHANCEMENT] Tighten Task.ask sequencing for auto-approved read-only asks #105