Define optional Sierra-to-CASM proof extension

[omarespejel]

Goal

Define the smallest interoperable optional extension for attaching a
Sierra-to-CASM compilation proof to a core Starknet source-verification record.

The first concrete example should use Starkscan's existing Argent Account
v0.3.0 fixture:

• fixture: verification/fixtures/direct-cairo-v1/argent-account-v0.3.0
• source revision: 53d01c0d6dce4fd30db955c3d698f658cdda1796
• expected Sierra class hash:
  0x01a736d6ed154502257f02b1ccdf4d9d1089f80811cd6acad48e6b6a9d1f2003

Reference proof work:
https://github.com/starknet-innovation/sierra-to-casm-compilation-proof

Context

The core evidence format answers whether a pinned source bundle rebuilds to a
Starknet Sierra class hash. A Sierra-to-CASM proof is a separate, optional
claim about the compiled-class hash Starknet executes. It must not change the
core exact-source decision or be required for a source-verification record.

Questions to resolve

• What is the smallest stable proof input and output interface?
• Which Sierra artifact digest and compiled-class hash must be bound?
• What proof/checker version and toolchain identity are required?
• Can the portable record contain only a bounded proof digest/reference?
• How should consumers distinguish verified, unavailable, rejected, and
  unsupported?
• Which fields belong in the core schema and which belong in a namespaced
  extension?

Proposed first contribution

Add a non-normative extension example and conformance vectors for:

• valid proof for the Argent fixture;
• wrong Sierra artifact;
• wrong compiled-class hash;
• corrupted proof;
• unavailable checker;
• deterministic replay.

The extension must bind to the core evidence digest, Sierra artifact digest,
chain, expected compiled-class hash, proof-system version, checker digest, and
proof digest/reference. It must not include unbounded proof blobs by default.

Acceptance criteria

• A maintainer can understand the extension without reading Starkscan code.
• A consumer can ignore the extension without changing the core result.
• The same inputs produce the same proof status and digest.
• Invalid or mismatched proof evidence fails closed as extension evidence.
• The first implementation can be reviewed in a separate Starkscan/Mezcal PR.
• The document clearly says this is proposed and not yet Verifier Alliance
  endorsed.

Scope boundary

This issue does not add public source submission, badge promotion, database
changes, signing authority, or a required proof step for source verification.