Fix/sla config version idempotency

[MerlinTheWhiz]

Description

Closes #29

Fix calculate_sla duplicate detection to compare config_version_hash in addition to mttr_minutes and threshold_minutes. Previously, submitting a duplicate outage_id after a set_config change would silently return the stale cached result, ignoring that the config (and therefore the deterministic result) had changed.

The doc comment on the duplicate check promises idempotency only when "execution inputs resolve to the same deterministic result." Since config_version_hash is part of those inputs, the comparison must include it to honour the contract invariant.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Related Issues

Relates to #29

Changes Made

• apexchainx_calculator/src/lib.rs: In calculate_sla, wrap the existing mttr_minutes/threshold_minutes duplicate check inside a config_version_hash equality guard. If the hashes differ (config was updated), execution falls through to the fresh calculation path — the new result is appended to history, stats are incremented, and events are emitted. If hashes match, the existing logic applies: same inputs → idempotent return, different inputs → DuplicateOutageInput error.
• apexchainx_calculator/src/tests.rs: Added 4 tests:
  • test_config_bumped_duplicate_treated_as_fresh_calculation — reward_base changed, same outage_id/mttr/threshold → recalculates with new config, history has 2 entries, stats show 2 calculations
  • test_config_bumped_duplicate_threshold_change_is_fresh — threshold lowered, same outage_id/mttr → result flips from met→viol
  • test_duplicate_same_config_still_idempotent — no config change → identical duplicate still returns cached result
  • test_duplicate_same_config_with_different_mttr_still_panics — same config, different mttr → still errors with DuplicateOutageInput

Testing

• Unit tests added/updated
• Integration tests added/updated
• Manual testing performed

All 393 tests pass (3 slow stress tests skipped). cargo fmt --all --check and cargo clippy --all-targets produce no new warnings.

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented complex logic
• I have updated relevant documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• My changes do not introduce new warnings

Screenshot (the 4 new added tests)

[usmanimamu17-create]

Excellent fix @MerlinTheWhiz! Your analysis of the idempotency invariant is spot-on — the doc-comment contract clearly says idempotency holds when execution inputs resolve to the same deterministic result, and config_version_hash is part of those inputs, so wrapping the existing mttr_minutes/threshold_minutes check in a config-hash guard was the right move. The four new tests pin down exactly the right matrix: bumped-config → fresh calculation with history+stats updated; threshold flip → met/viol reversal; same config + same inputs → cached idempotent; same config + different inputs → DuplicateOutageInput. 393/393 passing with no new clippy warnings — clean. Note: PR #48 (the rollback/finalize work for #32) has already landed on main, and the cross_contract_safety.rs / coordination_harness.rs changes here are byte-identical to those, so they apply as a no-op. Merging this one too.