RewardAccount: validate header type bits and bech32 prefix

[solidsnakedev]

Summary

RewardAccount parsing is looser than Address parsing for the same class of input. RewardAccount.FromBech32 does not check the bech32 human-readable prefix, and RewardAccount.FromBytes does not validate the CIP-19 header type nibble. As a result, a non-stake prefix and a non-reward header type can still parse into a RewardAccount. This is the RewardAccount-side counterpart to #391, which added the equivalent checks on Address / EnterpriseAddress / BaseAddress.

Affected

• packages/evolution/src/RewardAccount.ts — FromBech32 (prefix not checked)
• packages/evolution/src/RewardAccount.ts — FromBytes (header type nibble not validated)

Fix

• FromBytes: require the header type to be a reward type (14/15); reject others.
• FromBech32: require the prefix to be stake / stake_test and to agree with the header networkId.

Mirror the checks already present in Address.FromBech32.

Test

Add coverage asserting that a non-reward header and a non-stake prefix both fail to parse as a RewardAccount, and that valid stake / stake_test inputs still round-trip.

[solidsnakedev]

Sibling gap in the same bech32-HRP-validation family: KeyHash, ScriptHash, and PoolKeyHash FromBech32 decoders also skip the prefix check, so a pool1… string decodes as a KeyHash, etc.

• packages/evolution/src/KeyHash.ts FromBech32 (L111, bech32.decode L122) — should require addr_vkh / stake_vkh
• packages/evolution/src/ScriptHash.ts FromBech32 (L114, bech32.decode L125) — should require script
• packages/evolution/src/PoolKeyHash.ts FromBech32 (L69, bech32.decode L82) — should require pool

Same fix and same low priority as this issue; worth handling together. Not security (the node rejects the resulting output; caller must already hold the wrong-prefix string).