Rework shielded transactions

[l0r1s]

Summary

Companion PR to opentensor/polkadot-sdk#6

Reworks the MEV Shield from a store-then-decrypt model to a decrypt-at-proposal model.

Previously, encrypted transactions were stored on-chain (Submissions) and decrypted by the block author in a separate step, leaving a window where decrypted transactions sat in the pool before inclusion. Now, encrypted transactions travel through the pool as opaque ciphertext and the block proposer decrypts them inline during block building, including the inner extrinsic in the same block. There is no point where a decrypted transaction is visible before it lands in a finalized block.

Encryption uses ML-KEM-768 + XChaCha20-Poly1305 with per-block ephemeral keys rotated via an inherent.

Changes

pallet-shield (reworked)

• announce_next_key inherent: rotates CurrentKey <- NextKey each block and publishes the next block author's ML-KEM public key
• submit_encrypted extrinsic: accepts an encrypted ciphertext wrapper — the block proposer decrypts and includes the inner extrinsic in the same block
• try_decode_shielded_tx / try_unshield_tx: runtime helpers called by the block proposer via the ShieldApi runtime API
• CheckShieldedTxValidity transaction extension: pool validation checks ciphertext structure; block import additionally validates key_hash against CurrentKey/NextKey
• FindAuthors trait for resolving current and next block author
• Migration to clear removed v1 storage (Submissions, KeyHashByBlock)

stp-io (new crate — host functions)

• mlkem768_decapsulate: ML-KEM-768 decapsulation via the ShieldKeystore extension
• aead_decrypt: XChaCha20-Poly1305 decryption via the ShieldKeystore extension
• Exported as SubtensorHostFunctions for registration in the node

Node integration

• ShieldKeystore created in service.rs and threaded through to the proposer and inherent providers
• ShieldInherentDataProvider added to Aura consensus configuration
• KeyRotationService generates a new ML-KEM keypair on each own-block import
• SubtensorHostFunctions registered in the client executor

Runtime integration

• ShieldApi runtime API implemented
• CheckShieldedTxValidity added to the transaction extension pipeline

E2E test infrastructure (new)

• pnpm workspace under e2e/ with shared utilities (node management, chain spec generation, client helpers)
• e2e-shield test suite: 14 tests across 3 files covering key rotation, encrypted transactions (happy path, failure cases, rejection), 3-node and 6-node topologies
• Generic CI workflow (.github/workflows/e2e.yml) that auto-discovers testable packages and runs them in parallel

Tests

• Unit: key rotation, try_decode_shielded_tx, try_unshield_tx, depth-limit protection, inherent creation, CheckShieldedTxValidity extension (key_hash matching, malformed rejection, pool vs in-block source)
• E2E (3-node network): key rotation across blocks, author keys populated, encrypted tx happy path, failed inner tx, malformed ciphertext pool rejection, wrong key hash rejection, stale key rejection, multiple encrypted txs in same block
• E2E (6-node scaling): peering health, key rotation continues, encrypted tx works, multiple encrypted txs in same block
• E2E (edge cases): CurrentKey fallback, valid ciphertext with invalid inner call

[open-junius]

Seems it introduces the problem that the Ink contract doesn't work. I am not sure what is issue yet. Everything is fine in my local. #2450 created to debug it.