Prod token test: verify authorizer is set and consistent across vaults

[thedavidmeister]

Each receipt vault has an authorizer(). Add a fork test that verifies:

• The authorizer is not address(0) for any prod token
• All prod receipt vaults share the same authorizer contract

This would catch an authorizer being accidentally zeroed out or a vault being configured with a different authorizer than its siblings.

[thedavidmeister]

Blocked on rainlanguage/rain.vats#292.

OffchainAssetReceiptVault.authorizer() is defined on the concrete contract in rain.vats but isn't exposed by any interface in lib/rain.vats/src/interface/. Consumers — including this test — need a typed way to read the getter without importing the concrete implementation. Filed upstream to add IAuthorizableV1 (or extend IReceiptVaultV3).

Once that lands and the dep is bumped here, the test for this issue is straightforward:

• address mstrAuthorizer = IAuthorizable(MSTR_RECEIPT_VAULT).authorizer();
• per token: assert IAuthorizable(receiptVault).authorizer() != address(0) and equals mstrAuthorizer.

[thedavidmeister]

PR #116 up, assigned to @hardyjosh. Lands deliberately failing.

Drift surfaced on a Base fork: 11 of 13 prod tokens share authorizer 0x35f9fA9d80aAF2B0fB27f0FF015641B3408d7456; IBHG and SGOV diverge:

• IBHG → 0x6E0F1c31Fca4Ff07cD0C3e8658b1e3a473f3393a
• SGOV → 0xED3A1Ab65a25dfc82F4A7B89203EEc9BCb2D4f01

None match the V2 authorizer constants in LibProdDeployV2. PR body lays out three reads (misconfiguration / intentional per-token / cohort split) and what investigation is needed.

Upstream prerequisite landed: rainlanguage/rain.vats#293 / #292 added IAuthorizableV1, dep bumped here in #117 (now on main).