Implement conflict detection and integrate it into promotion-group execution

[ScottArbeit]

Implement real conflict detection for promotion groups and integrate it with the promotion model and the ephemeral-integration-branch workflow.

There is currently a stub contract for conflict detection in the foundation PR, but no actual implementation. This issue is to design and implement the conflict-detection layer and make sure its results are consumable by the rest of the promotion system (including the scheduler and UI/observability layers later).

Goals

• Provide a robust conflict-detection component that:
  • Can be invoked before and/or during promotion execution.
  • Uses the same semantics as the actual promotion application (branch merge/rebase behavior must be aligned).
  • Produces structured conflict results that can be:
    • Persisted in the promotion-group run record.
    • Displayed to users.
    • Used by higher-level policy components (e.g., “auto-skip groups that always conflict”).

Requirements

1. Use or extend the existing stub contract

   • Locate the existing stub contract for conflict detection added in PR Add promotion groups, BranchPromotionMode, and conflict-resolution policy (foundation) #28.
   • Flesh it out into an interface/service suitable for production use, e.g.:
     • Input: identifiers for promotion group, target branch, and the subset of changes/branches to be applied.
     • Output: a structured result type describing:
       • No conflict (safe to proceed).
       • Conflicts detected:
         • A list of conflicted files/paths.
         • Optional higher-level summary (e.g., count, severity, whether it’s auto-resolvable).
   • Keep the contract independent of any specific VCS implementation details where possible, but do not over-abstract prematurely.

2. Implementation strategy

   • Implement a concrete conflict-detection strategy that:
     • Uses the same merge/rebase semantics as the promotion executor (from the “ephemeral integration branch” issue).
     • Can be run in a “dry run” mode (detect conflicts without actually promoting to the target branch).
   • For Git-based backends:
     • Consider using merge-base + three-way merge simulation to detect conflicts.
     • Ensure detection behavior matches what would happen when the integration branch actually gets updated.

3. Integration with the promotion execution path

   • Integrate conflict detection into the promotion-group execution flow:
     • Pre-flight: optional conflict check before starting the integration branch application (useful for quick feedback and scheduling decisions).
     • During execution: when applying source branches onto the ephemeral integration branch, detect conflicts and halt execution appropriately.
   • If conflicts are detected:
     • Do not update the target branch.
     • Mark the promotion run as “conflicted” (or an equivalent status).
     • Record detailed conflict information in the promotion run record or related domain entity.

4. Domain model & persistence

   • Extend the promotion-group run model (or adjacent models) to include:
     • Conflict status (e.g., NoConflict, Conflicted).
     • Conflict details (list of file paths, optional summary).
   • Ensure this information is accessible through whatever query endpoints or application services already exist (or are being added) for promotion runs.

5. Configuration and extensibility

   • Design the conflict-detection service so that:
     • It can be replaced or extended later (e.g., to support additional backends or policy-based pre-checks).
     • It exposes a clear abstraction (IConflictDetector or similar) that is easy to mock for testing.

6. Testing

   • Add tests for:
     • No-conflict scenarios where a promotion would succeed.
     • Simple file-level conflicts (e.g., same file modified in both source and target branches).
     • Edge cases: rename + edit, delete + edit, etc., to the extent the current backing repository abstraction supports them.
   • Tests should verify:
     • The conflict-detection service returns accurate, structured results.
     • Promotion runs are correctly marked as conflicted, and the target branch is not updated.
     • Logging/events for conflicts are emitted and contain useful diagnostic information.

Deliverables

• A concrete implementation of the conflict-detection service based on the stub contract from PR Add promotion groups, BranchPromotionMode, and conflict-resolution policy (foundation) #28.
• Integration of conflict detection into the promotion-group execution path (including ephemeral integration branches).
• Extended domain model and persistence of conflict status/details on promotion runs.
• A suite of tests that verify behavior across no-conflict and conflict scenarios.