nostr: upgrade bitcoin_hashes to 1.x

[JSKitty]

Description

Bumps bitcoin_hashes from 0.14 to 1.1.

0.21.0 added SIMD SHA-256 Hardware Acceleration (ARMv8 crypto extensions, x86 SHA-NI, AVX2, SSE4.1), picked
by runtime feature detection with software fallback. The 0.14 line we currently pin is pure software on every target,

Measured on an Apple M4 Max:

	0.14	1.1
SHA-256, 64 bytes	226 ns	34.7 ns
NIP-44 v2 encrypt, 32-byte plaintext	2870 ns	1091 ns
NIP-44 v2 decrypt, 32-byte plaintext	2734 ns	995 ns

Machines without the relevant extensions (every Raspberry Pi, pre-Ice Lake Intel) fall back to
software and are unaffected either way. 1.x also wipes secret data in HMAC and HKDF, which the
0.14 engines did not.

These API changes were needed, all introduced by 0.21.0:

• HmacEngine<T> takes the engine type now instead of the hash type, so HmacEngine<sha256::Hash>
  becomes HmacEngine<sha256::HashEngine>.
• Hmac::from_engine(engine) becomes engine.finalize(), since HmacEngine implements
  HashEngine and finalizes to Hmac<T::Hash>.
• Hash::from_slice was removed, so ConversationKey::from_slice checks the length itself and
  calls Hash::from_byte_array.
• sha256::Hash::hash is an inherent method now, so the Hash trait import it used to need is
  dead in a few places.

Notes to the reviewers

This is a breaking change, however, given my obsession with low-level optimisation (particularly on the NIP44-v2 crypto paths; which are very heavily used in Concord Protocol and Vector Messenger), I believe this is a worthwhile change.

Behaviour is unchanged. Checked with a differential harness rather than relying on the
existing suite: 64 conversation-key derivations, 27 plaintext lengths covering every padding
boundary up to the 65408 maximum, MAC tampering, ciphertext tampering, all ten rejection paths
compared by exact error string, and 64 on- and off-curve x-coordinates, all folded into one
order-sensitive digest. Identical before and after
(c95d027371418aa7d71c0d86ea7cec49, 30 off-curve rejected / 34 accepted). Happy to include that
harness as a test if you'd find it useful.

I have a follow-up PR that cuts allocations in the NIP-44 v2 path (stack HKDF expansion, one buffer
for the payload, and a single curve parse in the ECDH derive instead of two). It's independent of
this PR and I'd rather keep them separate, so I'll open it once this is settled.

---

This PR was created from a deep performance R&D project, including the use of AI for automated benchmarking, with the mission of maximizing performance for Vector and Concord Protocol, reviewed by myself, Claude Fable 5 and DeepSeek-v4-Flash, I am aware of the contribution guidelines and I fully understand the changes being proposed.

Thanks for your consideration, there are many areas of performance enhancement I'd like to upstream from Vector to the Nostr Rust SDK / NostrDevKit. 🙏

Checklist

• I followed the contribution guidelines
• I updated the relevant CHANGELOG.md (if applicable)
• I understand and can explain all code in this PR

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[TheAwiteb]

LGTM, only couple changes

[JSKitty]

Handled the Codecov report, clippy, and applied your suggestions. 🙏 💚

[TheAwiteb]

@JSKitty Request my review when you are done

[TheAwiteb]

I have a follow-up PR that cuts allocations in the NIP-44 v2 path (stack HKDF expansion, one buffer for the payload, and a single curve parse in the ECDH derive instead of two). It's independent of this PR and I'd rather keep them separate, so I'll open it once this is settled.

Open a draft if you have something ready, we plan to release v0.45 in the next couple days. So we include your PR in the milestone, it's good one

[TheAwiteb]

ACK. Thanks

[yukibtc]

Thanks!

[yukibtc]

Squashed and merged at 8c7e9f6