[Feat]: Specify a Payment Evidence Frame for payment lifecycle receipts in task artifacts

### Is your feature request related to a problem? Please describe.

When a payment agent returns a receipt as a task artifact, an orchestrator has no documented, transport-agnostic way to do three things without parsing the inner domain format:

- identify what kind of payment receipt the artifact carries
- hold a stable reference identifier that survives re-serialisation and late signing
- detect tampering of the wrapped receipt

The docs specify Artifacts and Parts, but there is no page describing an envelope for payment lifecycle evidence carried inside them. Implementations are inventing their own wrappers, which do not interoperate.

### Describe the solution you'd like

Add a docs/topics page specifying a Payment Evidence Frame: a JSON envelope with a closed claim_type enum covering the payment lifecycle, a deterministic frame_id derived as SHA-256 over a JCS (RFC 8785) canonical preimage that excludes frame_id and signature, and an annotated example conforming to the Artifact and Part schema in a2a.proto.

Excluding the signature from the preimage is the load-bearing detail: it keeps a recorded frame_id valid when a frame is signed after the identifier has already been referenced elsewhere.

### Describe alternatives you have considered

Leaving the envelope to each implementation. That is the current state, and it is what produces the incompatible wrappers described above.

Putting payment receipt fields directly into the Agent Card or a registry record. That places lifecycle evidence in standing identity fields, which is the wrong lifetime for per-transaction data.

### Additional context

This is scoped strictly to payment lifecycle evidence. It is deliberately not a general admission or attenuation frame. The broader question of where verifier-side trust, permit, and receipt artifacts should live relative to A2A is #1769 and is not resolved by this.

Normative references: RFC 8785 (JCS), RFC 9421 (HTTP Message Signatures), and the Internet-Draft draft-hopley-x402-payment-evidence-frame.

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Review the existing Artifact and Part schema in a2a.proto. Read RFC 8785 (JCS) and the linked Internet-Draft to understand the canonicalization and envelope structure. The task is to create a new docs/topics page specifying the Payment Evidence Frame JSON envelope, including the claim_type enum, deterministic frame_id derivation, and signature exclusion. Ensure the example conforms to the existing proto schema.

Scritto dal modello di indicizzazione a partire dal testo della issue.