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

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.