Fix DefaultEncryption key reload on runtime compat flips + add regression coverage

[shaikh-shahid]

This PR fixes a runtime encryption bug in DefaultEncryption that could surface when core.compat changes after a session is already open (for example, when a manifest is learned later and persisted). It also adds a regression test that reproduces this transition and validates the fix.

Summary

Hypercore supports paths where a core starts without a local manifest and later receives one (for example, via session open with manifest, or replication manifest sync). When that happens, internal core.compat can transition at runtime. Encryption providers account for this by reloading derived keys when compat mode changes. Before this PR, that reload path was broken and could produce undefined keys, leading to runtime failures in decrypt/encrypt paths.

• Updated _reload in lib/default-encryption.js (/Users/shahidshaikh/Projects/hypercore/lib/default-encryption.js) to:

  • assign correct fields: keys.block, keys.blinding
  • update mode state: this.compat = core.compat

• Extended test/encryption.js (/Users/shahidshaikh/Projects/hypercore/test/encryption.js) with:

  • encryption reloads keys when manifest flips compat mode at runtime

• Test flow:

  1. Create a key-only core (manifest unknown locally)
  2. Reopen with compat: true
  3. Enable encryption
  4. Attach manifest via session (forcing compat transition)
  5. Trigger encryption path and assert keys remain valid

• Replaced test.solo(...) with test(...) in test/replicate.js (/Users/shahidshaikh/Projects/hypercore/test/replicate.js) so the full suite can execute normally.

Tests

• npx brittle test/encryption.js
  • Result: 16/16 tests pass, including the new regression test.
• npx brittle test/all.js
  • Result: Full suite now runs broadly (hundreds of tests).
  • Run in this environment stopped at a networking permission error (udx-native bind EPERM) during a replication networking test, indicating environment restriction
    rather than functional regression.