serviceability: add ip_verifier_authority_pk to GlobalState and rotate it via SetAuthority

[elitegreg]

Closes #4196. Part of RFC-27 (rfcs/rfc27-ip-verification.md); tracker #4194.

Summary

• GlobalState carries ip_verifier_authority_pk, the trust root for RFC-27 IP ownership proof validation, so the verifier key rotates without a program upgrade.
• SetAuthority gains an optional ip_verifier_authority_pk; authorization is unchanged (GLOBALSTATE_ADMIN permission or the legacy foundation path).
• doublezero global-config authority set --ip-verifier-authority <pubkey|me> rotates the key, and authority get reports it in both the table and JSON views.
• The Rust SDK SetAuthorityCommand forwards the new field.
• Pubkey::default() means "no verifier configured". Enforcement, which lands with the onchain validation issue, must treat that as a hard reject rather than as "any signature passes".

Details

The field is append-only, so accounts written before it existed deserialize with Pubkey::default() through the same unwrap_or_default() path feed_authority_pk uses. On the instruction side, BorshDeserializeIncremental keeps transactions built against the old argument layout decoding, with the new field defaulting to None.

SDK deserializer work for Go, TypeScript, and Python is tracked separately. The global_state fixture is regenerated here because CI's make check-fixtures diffs the goldens against the Rust producer; all three readers ignore trailing bytes and skip meta fields they do not map, so they stay green until that work lands. Running the generator also refreshed its Cargo.lock from 0.31.0 to 0.36.0.

smartcontract/cli/src/init.rs needed no change: it sends InitGlobalState and carries no authority arguments, and the program's initializer seeds the new field to Pubkey::default().

Testing Verification

• New tests/setauthority_test.rs: rotating the verifier key leaves the other authorities, the foundation allowlist, and the feature flags untouched; a second rotation replaces the previous key; and a later SetAuthority passing None does not clear it. It also asserts a freshly initialized GlobalState reads Pubkey::default(), the state enforcement must reject.
• Backwards compatibility against the committed base64 vector: it reads back Pubkey::default(), and re-serialized with the field set it round-trips with every other field identical. Note that this stored vector is old enough that its bytes end at user_airdrop_lamports, so appending 32 bytes to it would not have exercised the new field.
• SetAuthorityArgs unit tests: a pre-field four-option encoding still decodes with ip_verifier_authority_pk: None, and the new field round-trips.
• Go, TypeScript, and Python SDK suites pass against the regenerated fixture.

[juan-malbeclabs]

Approving — the change is sound and safe to land.

I read every hunk and traced the surrounding code: the GlobalState layout and its TryFrom, process_set_authority, try_acc_write → resize_account_if_needed, the borsh-incremental derive, the SDK fixture readers, and the remaining GlobalState { .. } literals in the tree.

The thing I specifically went looking for — the account growing 32 bytes on the first GlobalState write after the upgrade — is safe. Every processor that calls try_acc_write(&globalstate, ..) (setauthority, setairdrop, setfeatureflags, the four allowlist add/remove, and the five create_* index bumps) takes system_program as a fixed account, so resize_account_if_needed's invoke(transfer) always has it available. The append-only field, the unwrap_or_default() read path, and the BorshDeserializeIncremental instruction path all behave as advertised, and the legacy-vector test is a good way to pin that down.

No correctness bugs. The inline comments are all non-blocking — the first one is the only one I'd actually push for, and it's a three-line guard. They cluster around one theme: the field documents Pubkey::default() as a meaningful sentinel ("no verifier configured → enforcement must hard-reject"), but nothing in the write path, the read path, or the SDK goldens treats it as one yet. Worth closing before RFC-27 enforcement starts depending on that sentinel.

Ran locally: cargo test -p doublezero-serviceability --lib globalstate (9 passed) and --test setauthority_test (2 passed).