[Quality][Medium] Add upgrade compatibility checks for persistent records

[Baskarayelu]

Objective

Add compatibility fixtures and a pre-upgrade/post-upgrade validation path for core invoice, bid, and escrow records.

Why this matters

A contract upgrade can compile and deploy while changing the interpretation of existing records, which is more dangerous than a build failure.

This is a substantive production-quality improvement. It must change runtime behavior, security guarantees, correctness, reliability, or meaningful user functionality. It is not a documentation-only, formatting-only, or trivial dependency task.

Scope

Area: upgrade safety

Starting points: src/storage_types.rs, src/types.rs, scripts/check-wasm-size.sh, docs/id-stability.md

The contributor should verify the current implementation before changing it and keep the PR limited to this issue. Do not introduce unrelated refactors or weaken existing CI/security gates.

Acceptance criteria

• Representative records created by the previous schema decode identically after the upgrade.
• Changed fields have explicit defaults and cannot silently alter financial status.
• The compatibility check runs in CI against checked-in fixtures.
• The check fails on removed keys, changed discriminants, or incompatible field types.

Required validation

• Add serialized fixture tests for every core record.

• Test unknown/future fields and missing optional fields.

• Wire the compatibility check into the contract CI workflow.

• The PR explains the failure mode, the chosen design, backward-compatibility impact, and rollback or migration considerations.

• The PR includes CI evidence and does not contain secrets, generated noise, unrelated cleanup, or disabled checks.

Contributor deliverables

• Open a focused feature branch and do not begin implementation until assigned.
• Reference this issue with Closes #<issue-number> or Fixes #<issue-number>.
• Check off every acceptance criterion in the PR with links to the relevant code and tests.
• Include a security/correctness note explaining why adversarial inputs cannot bypass the new guarantee.

Maintainer quality bar

The PR must be independently reviewable, preserve existing behavior outside this scope, exercise failure paths, and pass the repository's complete required CI/CD checks. Reward eligibility is not guaranteed by this issue or by merging.

[best2025j]

i will like to work on this task please asign to me