RewardAccount: validate header type bits and bech32 prefix

## 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.

Start in packages/evolution/src/RewardAccount.ts at FromBech32 and FromBytes, then compare the existing checks in Address.FromBech32 and the related changes from #391. Add coverage for rejecting non-reward headers and non-stake prefixes while preserving valid stake and stake_test round trips; done means these cases parse or fail as specified.

Vom Indexierungsmodell aus dem Issue-Text verfasst.