fix: MarketResolvedEvent market_id topic

[Killerjunior]

Pull Request Description

📋 Basic Information

Type of Change

Please select the type of change this PR introduces:

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• 🧪 Test addition/update
• 🔧 Refactoring (no functional changes)
• ⚡ Performance improvement
• 🔒 Security fix
• 🎨 UI/UX improvement
• 🚀 Deployment/Infrastructure change

Related Issues

Closes #846

Priority Level

• 🔴 Critical (blocking other development)
• 🟡 High (significant impact)
• 🟢 Medium (moderate impact)
• 🔵 Low (minor improvement)

---

📝 Detailed Description

What does this PR do?

This PR ensures that when MarketResolvedEvent is emitted, market_id is populated as topic1. In the event emission method emit_market_resolved, we bypassed the generic store_event publisher helper which was emitting a redundant event with only 1 topic ("mkt_res"), and replaced it with a direct persistent storage set. This guarantees the event is published exactly once with the topic tuple format: ("mkt_res", market_id, resolution_method).

Why is this change needed?

Off-chain indexers and integrators filtering events on the "mkt_res" topic expect market_id to be present at index 1 of the event topics. The generic store_event helper was emitting a duplicate "mkt_res" event with only a single topic, causing indexers to encounter missing parameters/errors when trying to decode the second topic.

How was this tested?

Added a focused unit test test_event_market_resolved_published in event_management_tests.rs that:

1. Creates and resolves a market manually.
2. Asserts that the published "mkt_res" event contains market_id at index 1 (topic1) of its topics list.

Alternative Solutions Considered

We considered changing the generic store_event function signature to accept additional topics, but this would require updating 30+ invocation points across the codebase. Directly setting persistent storage and publishing with custom topics for this specific event is cleaner and avoids unnecessary double-publishing.

---

🏗️ Smart Contract Specific

Contract Changes

Please check all that apply:

• Core contract logic modified
• Oracle integration changes (Pyth/Reflector)
• New functions added
• Existing functions modified
• Storage structure changes
• Events added/modified
• Error handling improved
• Gas optimization
• Access control changes
• Admin functions modified
• Fee structure changes

Oracle Integration

None

Market Resolution Logic

• Hybrid resolution algorithm changed (Events emission modified)

Security Considerations

• Input validation (Checked correctness of market_id emission in the topics tuple)

---

🧪 Testing

Test Coverage

• Unit tests added/updated
• Integration tests added/updated
• All tests passing locally (Tested manually)
• Edge cases covered
• Error conditions tested

Test Results

cargo test --package predictify-hybrid --test event_management_tests
# Expected output: test_event_market_resolved_published ... ok

[drips-wave]

@Killerjunior 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