feat(policy): map --yolo to allowedTools wildcard policy

This PR maps the `--yolo` flag natively into a wildcard policy array
(`allowedTools: ["*"]`) and removes the concept of `ApprovalMode.YOLO` as a
distinct state in the application, fulfilling issue #11303.

This removes the hardcoded `ApprovalMode.YOLO` state and its associated
UI/bypasses. The `PolicyEngine` now evaluates YOLO purely via data-driven rules.

- Removes `ApprovalMode.YOLO`
- Removes UI toggle (`Ctrl+Y`) and indicators for YOLO
- Removes `yolo.toml`
- Updates A2A server and CLI config logic to translate YOLO into a wildcard tool
- Rewrites policy engine tests to evaluate the wildcard
- Enforces enterprise `disableYoloMode` and `secureModeEnabled` controls
  by actively preventing manual `--allowed-tools=*` bypasses.

Fixes #11303

docs/extensions/reference.md

@@ -253,10 +253,10 @@ Rules contributed by extensions run in their own tier (tier 2), alongside
 workspace-defined policies. This tier has higher priority than the default rules
 but lower priority than user or admin policies.
 
-> **Warning:** For security, Gemini CLI ignores any `allow` decisions or `yolo`
-> mode configurations in extension policies. This ensures that an extension
-> cannot automatically approve tool calls or bypass security measures without
-> your confirmation.
+> **Warning:** For security, Gemini CLI ignores any `allow` decisions or
+> `allow-all` wildcard configurations in extension policies. This ensures that
+> an extension cannot automatically approve tool calls or bypass security
+> measures without your confirmation.
 
 **Example `policies.toml`**