fix: implement flexible oracle result indexing per market

[maztah1]

Issue #117 / issue-9: Support Multi-Result Oracle Keys

• Add oracle_id parameter to set_oracle_result(market_id, oracle_id, outcome) replacing the hardcoded index 0 multiple oracle sources can now post results for the same market without key collisions
• Add get_last_update(market_id, oracle_id) to query the timestamp of the last update for any (market_id, oracle_id) pair
• Expose get_oracle_result and get_oracle_last_update as contract entry points in lib.rs so callers can query any oracle source by id
• Update all test callers of set_oracle_result to pass explicit oracle_id=0 (primary oracle) no behaviour change for existing single-oracle markets
• Add five focused unit tests in oracles_test.rs verifying:
  • Results stored under correct composite key
  • Updating one oracle_id does not affect others (isolation)
  • Same oracle_id in different markets is independent
  • get_oracle_result returns None for unset oracle
  • get_last_update returns None before any result is stored

Pull Request

📋 Description

Brief description of the changes in this PR.

🎯 Type of Change

• 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
• Performance improvement
• Code refactoring
• Test addition/update
• CI/CD update

🔗 Related Issues

Closes #(issue number)
Relates to #(issue number)

📝 Changes Made

• Change 1
• Change 2
• Change 3

🧪 Testing

Test Coverage

• Unit tests added/updated
• Integration tests added/updated
• All tests passing locally
• Test coverage maintained/improved

Manual Testing

• Tested on testnet
• Tested locally
• Edge cases tested

Test Results:

[Paste test output or describe manual testing performed]

📸 Screenshots (if applicable)

[Add screenshots for UI changes]

✅ Checklist

Code Quality

• Code follows project style guidelines
• Self-review completed
• Comments added for complex code
• No unnecessary console.log or debug code
• No commented-out code

Documentation

• Documentation updated (if needed)
• API documentation updated (if applicable)
• CHANGELOG.md updated
• README updated (if needed)

Testing & Quality

• All tests pass (cargo test)
• No linting errors (cargo clippy)
• Code formatted (cargo fmt)
• No new warnings introduced
• Gas benchmarks run (if applicable)

Security

• Security implications considered
• No sensitive data exposed
• Input validation added
• Authorization checks in place

Git

• Branch is up to date with main
• Commits are atomic and well-described
• Commit messages follow convention
• No merge conflicts

🔍 Reviewer Notes

[Any specific areas you'd like reviewers to focus on]

📊 Performance Impact

• No performance impact
• Performance improved
• Performance impact acceptable (explain below)

Details:
[Describe any performance implications]

🚀 Deployment Notes

[Any special deployment considerations, migration steps, or configuration changes needed]

📚 Additional Context

[Add any other context about the PR here]

---

By submitting this PR, I confirm that:

• I have read and followed the CONTRIBUTING.md guidelines
• My code follows the project's coding standards
• I have tested my changes thoroughly
• I am ready for code review

closes #117

[drips-wave]

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