Validate workflow update failure and recovery paths end to end #14

Parent: #11
Related: #7, #20

Goal

Prove that the update architecture fails safely before scaling it to many workflows and repositories.

Scenario status

• downstream patch no longer applies after an upstream change;
• upstream content does not match the expected SHA-256;
• generated template drifts from vendored source + patches;
• invalid catalog source fails before partially modifying the catalog;
• consumer update encounters local divergence and refuses to overwrite it;
• one template fails while other tracked templates can still render successfully;
• broken patch preserves a previous known-good generated template;
• missing cross-repository credential now fails early with a clear diagnostic;
• validate catalog publication/reconciliation against a real target repository;
• validate consumer divergence/failure recovery against a real target repository.

Expected behavior

• preserve previous known-good generated/published output where appropriate;
• surface a clear diagnostic;
• create a draft PR when human intervention is the intended recovery path;
• never silently publish a partially invalid workflow;
• make recovery reproducible after patch/configuration correction.

Current implementation

PR #21 added the missing recovery assertions and explicit token preflight.

Production validation of cross-repository publication/synchronization is blocked by #20 because the scoped cross-repository credential is not configured yet.

Acceptance criteria

Each scenario has an automated test or a documented integration test with the observed result.

Production validation now confirms successful GitHub App authentication, catalog reconciliation, consumer adoption and consumer no-op behavior. The remaining integration scenario is an intentional real-target consumer divergence/failure followed by recovery.