feat(truapi): development_createAccountProof for raw proof contexts

[peetzweg]

Adds a development-only way (no opt-in needed) for a product to bind a ring-VRF proof to 32 bytes of its choosing, instead of the blake2b("product/<id>/…") context the host derives for it.

Why: the namespacing means a product can only ever prove into contexts under its own product id. That blocks two things we need right now: runtimes whose ring-VRF contexts are string literals (e.g. pop:polkadot.network/score), which no product hash can equal, and one product (dim2.dot) proving into another product's context (people.dot). Both are needed to run the lite free-play flow end to end on nextv2 today.

How: two small pieces, each isolated so the whole hatch can be deleted in one go once the real mechanism lands.

• Host side (ring_vrf.rs): context_bytes is unchanged. A development module adds development_context_bytes, which returns the Raw suffix verbatim when the request carries the product id raw: (a marker dotNS cannot issue, so no real product reaches it) and otherwise calls context_bytes. The four proof/alias call sites in signing_host.rs and pairing_host.rs use it. No build flag or environment variable; the hatch is on in every host until it is deleted.
• Product side (@parity/truapi): development_createAccountProof(client, request) takes the exact shape of account.createAccountProof with context as a 32-byte hex string, fills in the raw: marker and forwards the call. It lives entirely in src/development.ts plus one re-export, carries a TODO and is documented as yet to be removed before a production release.

Why a marker in the existing message and not a new wire method: createAccountProof does not stop at the host; the request is forwarded over the SSO channel to whoever holds the key (phone app or truapi-host CLI). A dedicated development_create_account_proof would therefore need a new #[wire(request_id)] in the truapi trait, new request types and versioned envelopes, regenerated client and golden tests, a runtime.rs handler, an authority.rs method on both backends, new RemoteMessage request/response variants in the SSO protocol, and matching handlers in signing_host.rs, sso_responder.rs, pairing_host.rs and sso_channel.rs — plus a phone build that understands the new variant, and the same list in reverse to remove it, with the wire id staying burned. The raw: product id is a different value in a message all of those layers already carry, so nothing in between changes and deletion is local to ring_vrf.rs and development.ts. It is not an opt-in or a gate, only the discriminator that tells the signing host which function was called. Right design for a permanent feature, wrong one for something we intend to delete.

development_createAccountProof(client, { keyHandle, ringLocation, message, context: "0x…32 bytes…" });

Tests: bun test for the request shape and hex validation; the Rust hatch is a single guarded early return in front of the existing, still-tested context_bytes.