[P1] Stabilize ora.guard_id across semantically equivalent branch refinement guards #37
Description
Problem
ora.guard_id is generated from source location (file:line:column:length) plus kind/name, so semantically identical guards in different branches get different IDs. This prevents true guard-ID stability.
Evidence
Runtime output shows different IDs for equivalent guards:
guard:branch_guard_id_stability.ora:9:... vs guard:branch_guard_id_stability.ora:12:...
Impact
Equivalent guards can’t be recognized as the same logical guard across branches, causing noisy diagnostics and limiting guard dedup/cleanup opportunities tied to proven_guard_ids
Acceptance Criteria
- Guard IDs are derived from a canonicalized guard fingerprint (semantic), not source span.
- Equivalent branch guards in branch_guard_id_stability.ora produce the same ora.guard_id
- Non-equivalent guards still produce distinct IDs
- Add regression test asserting guard ID stability across branch duplicates
- Existing guard cleanup logic continues to work with the new ID scheme