breeze: add-repo command for ergonomic allowlist extension

[serenakeyitan]

Split from #291 item 6. Related: #293.

Problem

No way to extend the breeze daemon's allowlist without stopping it and re-starting with the full csv. Onboarding a second tree today means retyping all existing allow-repo entries.

Fix

`first-tree breeze add-repo /` — edits `~/.breeze/config.yaml` `repos:`, restarts the daemon with the merged list as the new allowlist.

Acceptance

• `breeze add-repo ` works idempotently (no duplicates).
• Daemon restarts (or reloads, if breeze start: silent no-op when daemon already running with different --allow-repo #293 ships `reload`) with the new repo in the allowlist.
• `breeze --help` shows the new command.

[serenakeyitan]

Blocked on a design question: breeze's `config.yaml` doesn't currently have a `repos:` field. The allow-list is CLI-arg only (`--allow-repo`) and isn't persisted anywhere the daemon reads on restart.

So `breeze add-repo ` needs to either:

1. Introduce a new `repos:` field in `~/.first-tree/breeze/config.yaml` as the persistent source of truth, teach `breeze start` to merge it with `--allow-repo`, and `add-repo` just edits the file + restarts. Cleanest.
2. Read the running daemon's allow-list (from the runtime status file that `breeze status` already reads via `runtime.get("allowed_repos")`), append, stop, and restart with the merged csv. No config change needed, but the logic lives entirely in `add-repo` and re-derives state from runtime every time.
3. Persist the last `--allow-repo` csv to disk on `start` (e.g. `~/.breeze/last-allow-repo.txt`), have `add-repo` read + edit + pass on restart.

Option 1 is the most durable; option 2 works but breaks if the daemon isn't running. Option 3 is the smallest change.

Deferring this until we pick one. Related fix for #293 shipped in #301 (loud failure on divergent-allowlist start).

[serenakeyitan]

Design options (follow-up to earlier comment)

Three concrete shapes for breeze add-repo:

Option A: New persistent repos: field in config.yaml

• What: Extend ~/.first-tree/breeze/config.yaml with repos: [owner/repo, …]. breeze start merges config.repos with --allow-repo CLI args. breeze add-repo <slug> appends to the yaml and restarts the daemon with the merged list.
• Pro: Clean source of truth. Survives reboots. Onboarding second tree is one command. Composes naturally with a future breeze remove-repo.
• Con: Two sources of allowlist truth (yaml + CLI flag) — need to document precedence clearly. Schema migration for existing config.yaml files.
• Effort: ~2 hours (schema + merge logic + add-repo command + test + restart path).

Option B: Read runtime allowlist from launchd plist

• What: On add-repo, parse the live daemon's launchd plist → extract the --allow-repo value → append the new slug → re-bootstrap with the merged csv. No config-file changes.
• Pro: Single source of truth (whatever started the daemon). No schema migration.
• Con: Tightly couples to launchd internals; doesn't work on the detached spawn fallback path. Fragile to plist format changes.
• Effort: ~1.5 hours but brittle cross-platform.

Option C: Persist last --allow-repo in a state file

• What: breeze start writes the effective allowlist to ~/.breeze/state/last-allow-repo.txt. add-repo reads it, appends, restarts. Yaml untouched.
• Pro: Minimal schema change. Works across launchd + detached paths. Easy to reason about.
• Con: Another file in the ~/.breeze tree. Can get out of sync if users hand-edit or start the daemon directly.
• Effort: ~1 hour.

Recommendation

Option A. The repos: field is the shape users expect (symmetric with hosts: etc.), and the precedence rule ("CLI flags override yaml for one-off runs, yaml is the persistent baseline") is a pattern they already know from other tools. B is too tightly coupled to launchd; C adds a stateful sidecar file that duplicates what yaml should own.

Which do you want?