account_hash_ignore_slot behaves incorrectly at genesis

[ripatel-fd]

Problem

Feature account_hash_ignore_slot removes the slot field from the BLAKE3 accounts hash.
On Solana Labs v1.17 test ledgers, this feature is activated by default (meaning there is a genesis account for the sysvar).

At slot 0, the bank's accounts delta hash is constructed from the hashes of all genesis accounts.

But even though this feature is active at the genesis slot, it uses the old method (before feature activation) to compute the genesis account hashes.

Proposed Solution

• Make sure features are activated before computing the account hash.
• Extend unit tests to cover genesis too.

[ripatel-fd]

Discussed this with @jeffwashington -- Since this has no impact on devnet, testnet, or mainnet, no immediate action required. It only affects new clusters, but is only a cosmetic issue. Resolving this would probably require large changes to ledger bootstrapping. Thus, the best way forward is to declare this behavior "correct" :)

Once the feature gate is activated, and the legacy behavior is removed, this will automatically fix itself.

[ripatel-fd]

@jeffwashington On further investigation, the problem goes deeper: Both hash versions are shared in the genesis slots. I'm not sure whether it's deterministic, but the pattern seems to be the following: Native programs and sysvars use the new hash version, and features use the old hash version. I'll report if I can match this behavior in Firedancer.

[ripatel-fd]

OK, pretty sure it's non-deterministic. I'll try to fix this upstream.

[ripatel-fd]

@t-nelson Could someone from the Labs team revisit this? Without this fix #32801 Solana Labs v1.16 cannot replay its own test ledgers. This makes it impossible to do any sort of cross-client work. (One of the reasons we are maintaining a long-term fork of Labs for Firedancer development)

[jeffwashington]

fyi #33692
@t-nelson , @ripatel-fd
I can manage this pr once we figure out it is right.