Doctor: scope release-campaign auth readiness to campaign intent on headless hosts

[jeffhuber]

Problem

A normal code-mower doctor --adoption run currently includes release-campaign provider checks even when the repository has no release campaign configured and the operator is adopting only the reviewer/orchestrator loop. On a headless Ubuntu host, the isolated Codex campaign home cannot use the required OS keyring, so doctor promotes an optional, unused release capability into an unsatisfiable owner action.

Observed in a metadata-only v1.3.1 adoption rehearsal: installation, normal Codex and Claude probes, Board, lanes, productivity, and a Devin-hosted session brief all worked, but doctor.campaign.auth [codex] required a keyring login the host could not provide. Claude campaign auth was reported differently, which made the readiness result harder to interpret.

Outcome

Default adoption readiness reports owner actions only for capabilities the selected adoption posture intends to use. Release-campaign authentication remains fully checked when a campaign is configured or explicitly requested.

Acceptance criteria

• Define one explicit, provider-neutral rule for when release-campaign readiness is part of adoption doctor.
• A repository with no campaign configuration or active campaign does not receive a campaign-auth owner action during ordinary reviewer/orchestrator adoption.
• An explicit campaign/adoption readiness request still checks every selected campaign provider and fails or warns accurately.
• Headless Linux produces actionable, truthful guidance. Do not recommend a keyring path that the detected host cannot support.
• Preserve credential isolation: never introduce readable auth.json, ambient-token inheritance, credential values, identity, paths, or raw probe output into public evidence.
• Keep Claude and Codex status semantics consistent where their real capabilities are equivalent; document product-specific differences.
• Add focused headless, configured-campaign, active-campaign, and no-campaign regressions plus privacy assertions.
• Deliver as one independently reviewed PR after Devin v1.4.0; it does not block Release: publish and qualify Code Mower v1.4.0 with Devin peer support #912.

Evidence

Reported from a hosted Ubuntu 22.04 v1.3.1 adoption run. P0/P1: none. This is the report's highest-priority P2 usability finding.