[cc] machine-like configurability — research strategies for first-class config

[anipotts]

Source: deferred from v3 imessage-alignment pass, decision 12

Problem

cc has env-var config for runtime knobs (`CC_STATE_DIR`, `CC_HEARTBEAT_MS`, etc) but no first-class config system. Env vars don't survive plugin reinstalls; per-project overrides require shell aliases; the `CC_STATIC_MODE` env var is declared but not wired.

Possible directions

• A. `cc(action='config')` verb — reads/writes `~/.claude/channels/cc/config.json`. Pro: MCP-native. Con: pollutes user-facing surface.
• B. Project-level .cc.json — gitignored, per-repo overrides. Pro: per-project diversity. Con: file scattering.
• C. Static mode (CC_STATIC_MODE) — boot-time freeze, refuse mutation. Imessage pattern. Pro: predictable. Con: requires reload.
• D. Hybrid precedence — default → env → file → per-call. Standard chain.

Open questions

• Concrete use case driving the design? Without one, this stays abstract.
• Does CC's plugin manifest already support a `config` schema field for user UI surfacing? (verify 2.1.122 spec)

Acceptance criteria (when ready)

• One of A/B/C/D selected with rationale
• Config persists across plugin reinstalls
• Documented in README + skill body
• Tests for config precedence

[github-actions]

@claude please triage this issue per .github/AI_REVIEW_RUBRIC.md (issue-triage section).