[GrantFox][High] Freeze storage key formats for upgrades

Summary

Freeze storage key formats for upgrades

Why this matters

A contract upgrade must not silently reinterpret existing market or oracle state.

Scope

Inventory storage keys, add compatibility fixtures, and reject incompatible migrations explicitly.

Acceptance criteria

• Every key family has a documented encoding.
• Populated upgrade fixtures load without loss.
• New keys cannot collide.
• Migration tests cover empty, populated, and malformed state.

Validation

Add regression coverage for existing behavior, failure modes, authorization boundaries, and compatibility. The implementation must pass the repository CI checks.

Non-goals

• Typo-only, formatting-only, or documentation-only changes.
• Unrelated refactors or dependency upgrades.
• Weakening existing security, authorization, CI, or production safeguards.

Contributor application

Before implementation, comment with relevant experience, a 1–4 bullet approach, and an estimate for opening the first draft PR. Wait for maintainer assignment before coding.

PR requirements

Use a feature branch, include Closes #<issue-number>, check every acceptance criterion, link criteria to code/tests, explain security and failure-mode considerations, and pass CI.

Reward-readiness

This is a substantive GrantFox campaign issue. Merge and CI success do not by themselves guarantee reward eligibility; final reward-readiness is determined by campaign review.

Begin by locating storage-key definitions and migration entry points in the Rust contract repository, then review existing upgrade and authorization tests. Build the inventory and compatibility fixtures described in the acceptance criteria, and use repository CI to verify empty, populated, malformed, and collision cases.