add: BLAKE2b (v2) block header support

[kwsantiago]

Bitcoin Knots v29.4.1 hardforks the PoW at mainnet 961,640 and testnet4 150,308. fork-observer can't read those headers, so nodes on that chain sit frozen at the last shared block.

Breakages:

• Headers are 164 bytes post-fork, not 80. chunks(80) desyncs and the REST batch fails. Esplora and mempool.space hit the same via consensus::deserialize.
• Version bit 31 flags v2 and is masked off before use. Read raw, it breaks the BIP-9 top-bits check.
• v2 hashes with BLAKE2b, so Header::block_hash() is wrong for them.

Adds a blake2b module that parses both versions, hashes each correctly, and serializes back to exact wire bytes. Headers travel as ParsedHeader (Header plus v2 fields). It derefs to Header, and its inherent block_hash() shadows the SHA256d one, so existing call sites stay correct unchanged. Can swap that for an explicit accessor if you prefer: same behavior, bigger diff.

Electrum, btcd and block-dn convert with .into(). The Core RPC path fetches the raw header now, since the typed model is fixed at 80 bytes and would silently return the wrong hash.

Scope: ingestion only. headertree.rs still ranks tips by cumulative work, so a BLAKE2b branch is tracked and drawn but never active. Ranking across two PoW functions is your call.

Tested against a Knots v29.4.1 testnet4 node across height 150,308: 133 headers ingested, every hash confirmed against the node, restart reloads from SQLite still correct. Unit tests use real headers from both networks. Build, test and fmt pass with --all-features.

Every block so far has flags & 3 == 0, so the other three hashing variants match the reference implementation but are unverified.

[0xB10C]

Thanks for the contribution, however, I'm not going to maintain BLAKE2b support in fork-observer and won't merge it here. My recommendation would be for you (or anyone else who wants to use it) to maintain this in a blake2b fork-observer fork.