Cross-product signing: a product can't createTransaction for another product's account of the same person

What we observe

As product A, asking the host to build/sign a transaction whose signer is a different product B's account (same person) is refused: Domain/V1/PermissionDenied. Reading B's account cross-product is fine with consent; signing for it is not.

Where it bites

The individuality game's free "lite invite" sign-up is a bind (unsigned, proof-authorised) plus a sign-up (Game.sign_up_with_account_lite_invite, signed by the playing account). We were exploring whether the personhood app (peopl.<tld>) could run the "sign up for the game" button for the person's game account (dim2.<tld>). The bind works today (it is unsigned, so peopl can stamp it); the sign-up can't — it must be signed by the dim2 account, and peopl gets PermissionDenied.

Reproduce

Self-contained repro (product scripts over a headless truapi-host), with on-chain results and the full write-up:

https://github.com/paritytech/lite-invite-signup

scripts/2-peopl-signs-up-dim2.ts binds the dim2 account from peopl (lands on-chain ✅), then hits PermissionDenied at the sign-up.

The ask

A consented way for one product to build/sign an extrinsic (createTransaction) for another product's account of the same person. #730 (Closes #655) makes cross-product ring-VRF proof work via the context grant; this is the extrinsic-signing counterpart — a different operation (createTransaction for another product's account) with a different refusal (PermissionDenied, not the proof's NotAllowlisted). Whether context should extend to cover it, or it needs its own scope, is your call.

Not yet a hard requirement

We have not confirmed this is required. The game's sign-up also carries the player's product-scoped communication identifier, so the sign-up may naturally belong with the playing product — in which case the dim2 product does its own sign-up (unblocked by #730's proof grant) and this capability is never needed. Filing so the gap is on record. It would add new cross-product capabilities and complexity we would rather avoid unless a product genuinely needs one product to sign for another's account. Full reasoning in the repo above.

Start with the linked lite-invite-signup reproduction, especially scripts/2-peopl-signs-up-dim2.ts, and compare the failed createTransaction/sign-up path with the working bind. Read #730 and its context grant discussion, then determine whether a consented signing scope is actually required; done means the capability need and its scope are explicitly decided.