Migrated from spboyer/waza#408

Summary

Expand .waza.yaml from 2 fields (engine, model) to a unified project configuration file covering execution defaults, cache, server, dev loop, token limits, grader defaults, and project paths.

Goal: Run waza init in any existing project, get a .waza.yaml, start running commands immediately with sensible defaults. No more typing --parallel --workers 8 --cache on every invocation.

Precedence

CLI flags > .waza.yaml > hard-coded Go const defaults

eval.yaml is untouched — each skill keeps its own.

Proposed Schema

7 sections, all optional:

• paths — skills/, evals/, results/ (const defaults when omitted)
• defaults — engine, model, judge_model, timeout, parallel, workers, verbose, session_log
• cache — enabled, dir
• server — port, results_dir
• dev — model, target, max_iterations
• tokens — warning_threshold, fallback_limit, limits (replaces .token-limits.json)
• graders — program_timeout

Sub-Issues

Phase 1: Config struct + YAML parser

• #409 — Define ProjectConfig struct with YAML tags
• #410 — Replace string parser with proper YAML config loader

Phase 2: Wire commands to read config

• #411 — Wire waza run to read .waza.yaml defaults
• #412 — Wire waza serve and waza dev to read .waza.yaml defaults
• #413 — Wire token warning threshold and program grader timeout to config

Phase 3: Token limits migration

• #414 — Fold .token-limits.json into .waza.yaml

Phase 4: Paths + waza init

• #415 — Add paths config and update waza init for existing projects

Phase 5: Schema + tests + docs

• #416 — Rewrite config.schema.json for expanded .waza.yaml
• #417 — Integration tests and documentation

Backward Compatibility

• Old 2-field .waza.yaml continues to work
• .token-limits.json honored during transition
• No behavior changes without user action