Wire consumers to read from `.github/caro/config.yml` (Pattern 5 activation)

[wildcard]

Context

Follow-up from oz-for-oss Pattern 5 (PR #1078). .github/caro/config.yml shipped as a tiered defaults file with knobs across defaults, triage, spec_pipeline, slash_router, release, coder_loop. None of the consumers currently read from it — the file is inert until wired up.

Wiring plan (each = separate small PR)

Priority 1 — highest leverage

• .github/workflows/slash-router.yml — read slash_router.commands to derive the whitelist (currently hard-coded in the case statement). Prevents SLASH_COMMANDS.md + config.yml + workflow drift.
• .claude/commands/caro-backlog-groom.md — read triage.default_priority and triage.do_not_touch_labels instead of hard-coding in Phase C.

Priority 2

• .claude/commands/caro-coder-loop.md — read coder_loop.max_reviewer_retries and coder_loop.fallback_specialist/documentation_specialist instead of hard-coding in step 6 (Reviewer gate) and step 4 (Pick specialist) fallback.
• caro.release.* skills — read release.publish_token_secret and release.msrv when composing release notes / verification steps.

Priority 3 — arrive with Pattern 4

• spec_pipeline.spec_label / impl_label / specs_dir — consumed by the future spec-from-issue-local.yml workflow (Pattern 4).

Consumer contract

The resolution rules encoded in .github/caro/config.yml header:

1. Look up the most-specific key under the consumer's section
2. Fall back to defaults
3. Fall back to a hard-coded sane value in the consumer

Each consumer PR should add a fallback so it degrades gracefully if config.yml is missing or a key is deleted — this avoids the config file becoming load-bearing without matching test coverage.

References

• .github/caro/config.yml — the data file
• .claude/rules/release-version-alignment.md — related invariant (MSRV / version references)

/cc @wildcard