[Quality-2][High] Bound oracle deviation and fallback semantics

[greatest0fallt1me]

Summary

Implement Bound oracle deviation and fallback semantics as a production-ready change in Predictify-org/predictify-contracts.

Why this matters

The implementation must be deterministic and reviewable so normal operation and adverse conditions do not cause silent data loss, inconsistent state, security regressions, or an unrecoverable user experience. This issue specifically requires least privilege, input validation, abuse resistance, and authorization boundaries.

Scope

Trace the relevant entry points, state model, and failure paths; implement the smallest complete design; preserve public interfaces unless a compatibility plan is included; and document important invariants in code.

Priority

High

Acceptance criteria

• The intended behavior is deterministic for valid, invalid, duplicate, and boundary-case inputs.
• Authorization, validation, and state-transition invariants remain enforced.
• Retries, partial failure, and concurrent execution cannot produce an unsafe or inconsistent result.
• Focused tests cover success, rejection, boundary, and regression scenarios.
• Existing callers remain compatible, or the PR includes a tested migration path.
• Relevant logs, metrics, or user-visible errors make failures diagnosable without exposing sensitive data.

Validation

Run focused tests and repository CI checks with evidence for normal operation, invalid input, retries, concurrency or timing boundaries, and failure recovery where applicable.

Non-goals

• Typo-only, formatting-only, documentation-only, or cosmetic changes.
• Unrelated refactors, dependency upgrades, or broad rewrites.
• Removing safeguards or weakening validation to make tests pass.

Contributor application

Before coding, describe affected modules, proposed state/invariant changes, test strategy, compatibility considerations, and an estimate. Wait for assignment before starting implementation.

PR requirements

Use a feature branch and include Closes #<issue-number>. Address every criterion, map criteria to code and tests, explain security and failure-mode handling, and ensure CI passes.

Quality review

A maintainer will assess correctness, completeness, test depth, compatibility, observability, and adverse-case handling. A substantive implementation is required; merge or CI status alone does not guarantee reward eligibility.

[felixumeh]

@felixumeh has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Please I would like to work on this issues and give PR

ℹ️ Repo Maintainers: To accept this application, review their application or assign @felixumeh to this issue.

[drips-wave]

Congratulations, @osaa4! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @osaa4: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊