Parity Tier 2: add scheduled cadence + governance-appropriate API-key sourcing

[mlieberman85]

Context

Feature 028 (spec at specs/028-audit-parity-tests/spec.md, PR TBD) ships Tier 2 (coding-agent skill vs raw tool output parity) as manual-dispatch only for the MVP. See FR-007, FR-007a, FR-007b, SC-005a.

The reason is governance, not cost: the darnit repo is under neutral governance, and the ANTHROPIC_API_KEY that would run Tier 2 belongs to a specific company. Automated scheduled runs would charge that company's account for community-triggered activity, which is inappropriate for a project not owned by that company.

What this issue asks for

Design and implement a governance-appropriate model that lets Tier 2 run on a schedule (nightly is the natural default) without charging any single company for community-triggered activity.

Options to evaluate

• Community-owned API key with a monthly cap. A budget-limited key held by the project (via GitHub org's billing account or a foundation-managed vendor account). Simpler ops; harder to arrange.
• BYO-key per maintainer. Each maintainer optionally provides their own key when triggering a run. Loses "unattended nightly" property; re-opens the "arbitrary community actor" hole unless combined with the reviewer gate.
• Reviewer-approved scheduled runs. GitHub Environment with approval gate on the scheduled trigger; a designated on-call reviewer approves each nightly run. Preserves accountability but adds friction.
• A rotating key allocation across sponsor companies with usage caps per company. Complex; only worth it at higher volume.
• Move Tier 2 out of the darnit repo to a company-owned repo whose owner explicitly consents to being billed. Cleanest governance; loses the "diagnosis lives with the artifact it diagnoses" property.

Prerequisites

• Feature 028 (this feature) must merge first so the Tier 2 workflow definition exists to extend.
• Governance decision on which model matches the project's stance on shared costs. That may be a TSC-scale question if it doesn't fit within the maintainer group's day-to-day scope.

Constraints from feature 028 that MUST be preserved

• FR-007a: no key exposure to workflows outside the gated Environment.
• FR-007b: no operator-provided key inputs (unless a subsequent decision re-opens BYO-key).
• SC-005a: grep-verifiable exclusive key access.

Related

• Feature 028 spec: specs/028-audit-parity-tests/spec.md (Q3 clarification on 2026-08-09).
• Project org migration context: .claude/projects/-Users-mlieberman-Projects-darnit/memory/project_org_migration.md (repo moved off kusari-oss to darnitdevorg under neutral governance).