[saoirse-a]

A block-level "trusting " scope holds an index into that block's own public-key list. For a third-party block that list is independent of the token's. Authorizer passed the raw indices to TrustedOrigins.fromScopes along with publicKeyToBlockId, which is keyed by indices into the authorizer's table, so the scope could resolve to a different key than the one the block names. A key the token holder had introduced could end up trusted in place of the intended one, and the intended key was no longer trusted.

Translate block scopes into the authorizer's index space before computing trusted origins, in both updateOnToken and authorize, using Scope.convertFrom with the block's own table followed by Scope.convert into the authorizer's table. This is how rule-level and check-level scopes are already handled.

convertFrom narrows the 64-bit key index to an int and assumes the key exists, so validate the index against the block's public-key list first. A scope naming a key the block does not declare now fails with the new LogicError.InvalidBlockScope instead of wrapping around to another key or throwing an unchecked exception.

Add two tests to ThirdPartyTest that build a token where index 0 differs between the two tables:

• testThirdPartyBlockLevelScopeRejectsFactFromUntrustedKey: mfa(true) is signed by an unrelated key, so the check must fail.
• testThirdPartyBlockLevelScopeAcceptsFactFromTrustedKey: mfa(true) is signed by the partner key named in the scope, so the check must pass.