feat: allow safety mode defaults to be configured in YAML

[Sayt-0]

Summary

Follow-up to #3835.

#3835 introduces the strict, balanced, and autonomous safety modes. The mode can currently be selected through --safety, the legacy --yolo flag, or the session API, but it cannot be declared in YAML.

Add declarative safety mode defaults at the team, agent, and user levels.

Proposed configuration

Team-wide default, with an optional per-agent override:

runtime:
  safety: balanced

agents:
  root:
    model: anthropic/claude-sonnet-4-5
    instruction: You are a general-purpose assistant.

  reviewer:
    model: anthropic/claude-sonnet-4-5
    instruction: Review changes without modifying files.
    safety: strict

  automation:
    model: anthropic/claude-sonnet-4-5
    instruction: Run trusted automation.
    safety: autonomous

Optional user-wide default:

# ~/.config/cagent/config.yaml
settings:
  safety: balanced

runtime.safety applies to every agent in the team unless the selected agent defines its own safety value.

Proposed precedence

For a new root session:

Priority	Source
1	Explicit --safety
2	Explicit --yolo, equivalent to autonomous
3	User-owned alias options
4	settings.safety or legacy settings.YOLO
5	agents.<selected-agent>.safety
6	runtime.safety
7	Existing unset behavior

When both --safety and --yolo are passed, --safety wins, matching #3835.

The existing unset behavior must remain unchanged: read-only annotated tools may run automatically, while other calls require confirmation.

Session semantics

• YAML values are defaults used when creating a new root session.
• Resuming a session without an explicit CLI override preserves the safety mode stored in that session.
• Switching or handing off to another agent must not silently replace a mode already selected by the user.
• Delegated and spawned sessions should continue inheriting the parent session’s effective safety mode.
• An explicit --safety or --yolo may still override the stored mode when resuming.

Compatibility

• Only strict, balanced, and autonomous should be accepted in new YAML fields.
• Invalid values should fail configuration loading with a clear error.
• Existing settings.YOLO, alias yolo, and --yolo behavior must remain supported as aliases for autonomous.
• If both safety and the legacy YOLO value are configured at the same scope, safety should win.
• Configurations that omit all safety fields must retain the current behavior.

Security consideration

Agent configurations can be loaded from local files, URLs, or OCI references. An author-provided YAML must not silently weaken a user-owned global safety preference.

The implementation should explicitly decide whether autonomous is allowed in runtime.safety and agents.<name>.safety, or whether it should only be selectable from user-owned settings and explicit CLI/API input.

Acceptance criteria

• runtime.safety defines a team-wide default.
• agents.<name>.safety overrides the team default for a newly created root session using that agent.
• settings.safety defines a user-wide default and cannot be silently weakened by downloaded agent configuration.
• CLI overrides follow the documented precedence.
• Resumed sessions keep their persisted mode unless explicitly overridden.
• Agent switches and delegated sessions do not unexpectedly reset the active mode.
• Legacy YOLO and yolo settings remain compatible.
• Invalid YAML values produce a clear validation error.
• agent-schema.json, configuration documentation, and the safety modes example are updated.
• Tests cover defaults, precedence, resume behavior, agent selection, and backward compatibility.

Non-goals

• Changing the safety classifier or the mode decision table introduced by feat: three-mode safety policy (strict / balanced / autonomous) with native shell classification #3835.
• Dynamically changing the safety mode whenever the active agent changes.
• Replacing fine-grained allow, ask, and deny permission rules.