conformance: cover Tempo subscriptionId in Payment-Receipt round-trips

[Osraka]

Summary

Tempo subscription receipts include a top-level subscriptionId, but the MPP conformance receipt contract cannot represent or test it today. This lets an SDK pass the existing receipt vectors while silently dropping the identifier that applications need for renewal, cancellation, support, and reconciliation.

Evidence

• The Tempo subscription documentation says activation returns a Receipt with subscriptionId and lists it as a server-issued receipt field: https://mpp.dev/payment-methods/tempo/subscription
• The subscription guide asks applications to persist subscriptionId: https://mpp.dev/guides/subscription-payments
• mpp-rs already models the field as optional and has round-trip plus foreign-receipt preservation tests.
• conformance/schemas/protocol.schema.json defines Receipt with additionalProperties: false and only permits status, method, timestamp, reference, externalId, and extra.
• conformance/vectors/receipt.json has no subscriptionId scenario.
• The Go adapter maps only those existing receipt fields, so a top-level subscriptionId has no canonical representation in the adapter ABI.

Local reproduction

Validating a documented Tempo subscription receipt against the current Receipt schema rejects it:

Additional properties are not allowed ('subscriptionId' was unexpected)

Input:

{
  "status": "success",
  "method": "tempo",
  "timestamp": "2026-07-12T00:00:00Z",
  "reference": "0xabc",
  "subscriptionId": "sub_123"
}

Proposed direction

Before preparing a PR, I would like maintainer guidance on the intended contract:

1. Add optional top-level subscriptionId to the canonical conformance Receipt schema and add parse/format/round-trip coverage across adapters; or
2. Model it as a Tempo-subscription-specific capability/vector so SDKs whose current receipt APIs cannot expose it do not claim that support.

Either way, the vector should ensure a receipt produced by one SDK does not lose subscriptionId when parsed and formatted by another. I have not opened a PR because this choice affects the public adapter ABI and pinned SDK-version policy.