Drop dotNsIdentifier from account/signing methods and add permissioned external-account access

[valentinfernandez1]

Context

The account, signing, and statement-store methods all take a ProductAccountId { dotNsIdentifier, derivationIndex }:

• getAccount()
• getAccountAlias()
• createAccountProof()
• createTransaction()
• signRaw()
• signPayload()
• statementStore.createProof()

Problem

The host already knows the calling product's dotNS domain, so making the product pass dotNsIdentifier is redundant. The host can resolve it on its own.

The parameter also has no useful value other than the caller's own domain. The host only ever acts on the domain the product is currently running under: if a product passes any other dotNS address, the host rejects the call as invalid. For example, a product running on truapi-playground.dot that calls signRaw() with a different dotNS address (say another-product.dot) gets back an invalid response, it can't reach the other product's account this way.

So dotNsIdentifier can only ever echo the caller's own domain (redundant) or name a domain the host refuses (a dead value). Either way it shouldn't be on the default call surface. Products should be isolated to their own accounts by default, and the host should be the sole authority on which domain a call resolves against.

Proposal

1. Drop dotNsIdentifier from the default methods

The methods resolve against the caller's own dotNS domain. Products pass only derivationIndex:

// Before
await truapi.account.getAccount({
  productAccountId: { dotNsIdentifier: "truapi-playground.dot", derivationIndex: 0 },
});

// After
await truapi.account.getAccount({ derivationIndex: 0 });

This applies to all seven methods above.

2. Add permissioned external-account access

Today these methods only ever reach the caller's own account; there's no way to reach another product's account (the host rejects any other domain). Some products may have a real reason to read, and possibly sign with, another product's account, so we should add that capability explicitly and behind a permission instead of overloading dotNsIdentifier.

• New permission. Add a RemotePermission variant (ExternalAccount) in permissions.rs so cross-product access is grantable and deniable by the user like the other remote permissions.
• Explicit external methods. Add mirror methods that take an explicit target identifier and require the ExternalAccount grant: getExternalAccount(), getExternalAccountAlias(), createExternalAccountProof().
• Signing needs more thought. Whether to allow signing with an external account at all is a separate decision. If we do, gate createExternalTransaction(), signExternalRaw() and signExternalPayload() behind the same (or a stricter) permission and a per-signature prompt.

Open questions

• One ExternalAccount permission for everything, or split read from sign?
• Should we even consider sign in the scope?

@pgherveou @filvecchiato @TorstenStueber would really appreciate your input on this