RFC: Remove dotNsIdentifier from default account access

[valentinfernandez1]

Summary

This is part 1 of a 2 part split of #243:

Today every account/signing/statement-store call takes a ProductAccountId { dotNsIdentifier, derivationIndex }. The dotNsIdentifier is redundant, the host already knows the calling product's domain and a dead input: pass any domain other than your own and the host just rejects it as invalid on signing related calls.

So it's removed from the request bodies. Callers pass only derivationIndex, and the host resolves the caller's own dotNS domain itself:

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

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

Seven request bodies lose their ProductAccountId field in favor of a bare derivation_index: u32:

• Account: getAccount, getAccountAlias, createAccountProof
• Signing: createTransaction, signRaw, signPayload
• Statement Store: createProof

ProductAccountId itself stays defined and exported, unused for now, so Part 2 can reuse it as the explicit external-account identifier.

Includes RFC-0022 with the full rationale.

Part 2 (follow-up): add the permissioned external-account access described in the issue, a new ExternalAccount permission plus explicit external methods that take a full target identifier.

[valentinfernandez1]

Keeping as draft for now as this is a big breaking change and we need to settle on the best versioning strategy for this

[valentunn]

The dotNsIdentifier is present there intentionally: some products are interested in requesting accounts of other products

Hard NO from my side