[GrantFox][Medium] Stabilize public error mapping

Summary

Stabilize public error mapping

Why this matters

Client applications need consistent decoding when contract errors evolve.

Scope

Version public error codes and preserve compatibility for existing callers.

Acceptance criteria

• Existing codes remain stable.
• New codes are unique and documented.
• Unknown values decode safely.
• Golden vectors cover public entrypoints.

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.

Start by locating the public error definitions, decoding entrypoints, and existing compatibility or golden-vector tests in the repository. Review how current codes and authorization failure modes are represented, then use the acceptance criteria and repository CI checks to verify stable codes, unique documented additions, safe unknown-value handling, and coverage of public entrypoints.