Fix environment-qualified host compatibility

[replghost]

Summary

• Accept exact environment-qualified account aliases emitted by released product SDK containers.
• Run independent resource allocations concurrently while preserving response order.
• Register network-qualified aliases for the canonical Lite Person ring key.

[pgherveou]

This breaks RFC-0024's rule on foreign-key proofs

account_create_account_proof now offers a user-prompt fallback for a foreign key_handle. RFC-0024 forbids exactly that.

The runtime-level NotAllowlisted guard is gone from create_account_proof, so the call reaches SigningHost::create_proof. When the handle is a peopl.* Lite Person alias, that path calls account_access_authorization, which prompts the user (rust/crates/truapi-server/src/runtime.rs:751) and persists the answer (runtime.rs:763), so every later proof for that product is silent.

docs/rfcs/0024-personhood-as-product.md:240: "The allowlist is the only authorization for these two calls. A user prompt is not a substitute and MUST NOT be offered as a fallback: consenting to an opaque message is not meaningful consent, and the risk being accepted is one only the key's owner is positioned to evaluate." Line 302 accepts, deliberately, that foreign proofs stay unavailable until the manifest RFC lands.

Two details make that concrete here. context is caller-supplied and never checked against the calling product (context_bytes, runtime/signing_host/ring_vrf.rs:215), and the Lite Person key is the one pallet-alias-accounts consumes, which the RFC calls out by name at line 234. So one tap on a generic "account access" dialog grants personhood proofs under any context, indefinitely.

The argument for the change is reasonable: the gate requires the handle to resolve to the wallet's own canonical Lite Person key, so no other product's key is reachable, and peopl.* is a reserved id with no manifest to allowlist from, so waiting for the manifest RFC leaves this permanently unavailable. If that is the intent, it belongs in an RFC-0024 amendment rather than in a silent deletion of the guard, ideally pinning context.product_id to the caller and wording the confirmation for what is actually being granted.

As it stands the three paths disagree: account_ring_vrf_sign (runtime.rs:1231) and PairingHost::create_proof (runtime/pairing_host.rs:2125) both still enforce the old rule.