[Capability Pilot] Bounded consumer-sync drift remediation

[stranske]

Problem

Consumer synchronization is centrally declared, but its source-resolution behavior is duplicated across sync, drift, hashing, and validation surfaces. That makes drift harder to diagnose and prevents the automation system from treating bounded consumer-sync remediation as a measurable capability.

Outcome

Deliver a typed, observable, shadow-first capability that can recognize consumer-sync drift, compile one normalized plan, record effect evidence, and demonstrate when bounded remediation is safe enough to promote.

Scope

• Compile .github/sync-manifest.yml into one typed normalized plan used by sync and validation surfaces.
• Extend the existing agent-runner evidence contract with optional capability/effect fields.
• Reuse Orchestrator's existing capability:reference-sync-hygiene-test-gate and completion-event lifecycle.
• Operate remediation in read-only shadow mode before any write authority is considered.
• Measure successful recognition, plan correctness, avoided human intervention, counterexamples, and rollback readiness.

Non-goals

• No arbitrary shell execution from a manifest or completion event.
• No new capability ledger, event log, or promotion lifecycle.
• No autonomous merge, repository deletion, or unbounded fleet writes.
• No immediate activation of write-side remediation.

Delivery issues

• Compile consumer sync manifest into one typed normalized plan #2751
• Bridge agent-runner capability and effect evidence into Orchestrator #2752
• Extend the reference shadow capability for consumer-sync drift remediation #2753

Acceptance criteria

• One normalized manifest plan drives all covered sync/drift/hash/validation decisions.
• Runner evidence can name a capability, its effect fingerprint, artifact reference, and supervision mode without breaking existing consumers.
• The existing shadow capability can ingest consumer-drift evidence and report promotion blockers.
• Shadow evaluation includes deliberate-break and counterexample fixtures.
• Promotion requires measured benefit, bounded failure behavior, TTL/kill switch, and rollback evidence.
• Each child issue has its own branch, tests, and PR.

Verification

• Run the targeted Workflows validation suites named in each child issue.
• Run Orchestrator capability, completion-event, and workflow-compiler self-tests.
• Confirm the Orchestrator canonical and mirror files are byte-identical.
• Review the shadow report; no write-side action may occur during this pilot.