Operational repos: audit ground truth should be main (stable snapshot), not develop #340

Context

Filed from the HomeAssistant-Config #16 operational onboarding. This is a deliberate disagreement with the current groundTruthBranch convention for operational repos, raised for a fleet-wide decision.

Observation

groundTruthBranch is inconsistent across operational (workflowModel: operational) repos:

Three operational repos audit against develop; HomeAssistant-Config was deliberately kept on main. The registry default is main.

Position: operational repos should audit against main, not develop

The audit's ground truth is the "known-good reference state" a repo is measured against. For an operational repo that should be main, for the same reasons the release repos already audit main:

• main is the promoted, gated, known-good snapshot. repo-config/README.md describes the operational model as "edit develop directly and promote a known-good snapshot to main via an occasional PR." The promotion gate (PR + required status check + Copilot review + resolved threads + signed merge commit) exists precisely so that main is the trustworthy state. Conformance should measure that trustworthy state.
• develop is mid-flight by design. It takes direct, ungated signed commits with no PR gate. Auditing it measures work-in-progress: a half-finished live-config edit, or a conformance file that has landed on develop but not yet been promoted, reads as "drift" or a LETTER finding that is not a real defect - only an un-promoted change. (Concretely in #16: carrying the baseline to develop would leave the repo-config/... absent LETTER standing against a develop ground truth until promotion, even though the work is done.)
• Consistency. Release repos already default to main; there is no model-specific reason an operational repo's reference branch should differ. The operational model changes how develop is written (direct vs PR), not which branch is the stable reference.

Proposal

• Default operational repos to groundTruthBranch: main (drop the operational-specific develop choice), and revisit Vantage-Config, ESPHome-Config, and HomeAutomation-Config.
• Keep HomeAssistant-Config on main (already done in #16).

Counter-view (acknowledged)

If an operational repo is deployed directly from develop (develop = live production), one could argue develop is the state worth auditing. Even then, the fleet-conformance scaffolding (repo-config/, AUDIT.md, spec/secrets.json, workflows) is stable infrastructure that belongs on the gated branch, and a develop ground truth turns "not yet promoted" into a standing finding. If deploy-from-develop is the real driver, that argues for a separate deployBranch field rather than overloading groundTruthBranch.

Raised per the HomeAssistant-Config owner's decision in #16.