feat: Add default gas regression limits for market and claim paths

[sheyman546]

Closes #1412

---

What it fixes

Adds default gas regression limits for the two highest-traffic critical paths in the Predictify Hybrid contract: create_market and claim_winnings.

Root cause

The existing GasTracker infrastructure had hooks (start_tracking/end_tracking) and enforcement logic (panic_with_error!(GasBudgetExceeded)), but no limits were actually configured. The performance_benchmarks.rs file defined threshold constants, but these were only used in benchmark tests — never wired into runtime enforcement.

This meant:

• A code change could double the gas cost of create_market or claim_winnings without any runtime or CI failure
• The claim_winnings path had no gas tracking at all (no start_tracking/end_tracking calls)
• The record_with_alert low-water alert system only checked admin-configured limits, not defaults
• The CI gas regression workflow used hardcoded dummy values that would always pass

The fix

1. Default regression limit constants in gas.rs:

   • DEFAULT_CREATE_MARKET_GAS_LIMIT = 5,000,000 CPU instructions
   • DEFAULT_CLAIM_WINNINGS_GAS_LIMIT = 2,000,000 CPU instructions

2. GasTracker::end_tracking now falls back to default limits when no admin limit exists (admin override > default > unchecked)

3. GasTracker::set_default_limits() seeds limits during initialize(), ensuring they're always active

4. claim_winnings now has start_tracking/end_tracking calls (previously untracked)

5. record_with_alert now respects default limits for the 90% low-water alert

6. Helper methods has_limit() and get_effective_cpu_limit() for introspection

7. 20 unit tests covering enforcement, admin overrides, edge cases, and boundary conditions

8. CI workflow updated to run the regression test suite with real baseline values

How it was tested

• 20 new unit tests in gas_regression_tests.rs covering:
  • Default limit value sanity checks
  • Limit seeding during initialization
  • Enforcement via end_tracking (within/at/exceeding limit)
  • Admin override precedence (tightening and loosening)
  • has_limit and get_effective_cpu_limit
  • record_with_alert with default limits
  • Edge cases: zero cost, untracked operations, sequential calls
• All existing tests remain compatible (limits are generous with 10x headroom)

What could break

• False positives: If market creation legitimately exceeds 5M CPU (unlikely with current mock-delta p95 of ~500), the limit would need tightening. Mitigated by conservative 10x headroom.
• Admin override interaction: Admins can override defaults via existing set_limit() API. The precedence is clear (admin > default), but admins should be aware defaults now exist.

Follow-up (file separately)

1. Add default limits for vote and resolve_market paths
2. Tighten limits with real stellar contract invoke --cost p99 measurements
3. Add CI gas measurement step that builds WASM and measures actual gas
4. Store baseline gas values in a JSON file for CI

[drips-wave]

@sheyman546 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits