feat(server): build, sign, and submit Bulletin preimages in the core

[pgherveou]

What

Preimage submission to the Bulletin chain now happens entirely inside the Rust core (truapi-server).
The core builds, signs, and submits the TransactionStorage.store extrinsic itself, routing chain traffic through the host's existing chain.connect JSON-RPC pipe.

Previously the core handed the host a signing capability and the host built and submitted the transaction with PAPI.
That seam is gone. As a result:

• the wallet-delegated allowance secret is only ever used inside the core: no signer handle and no sign request crosses the host / FFI boundary, and the key arrives from the wallet end-to-end encrypted
• the host's only remaining preimage job is content lookup (smoldot bitswap, or an IPFS HTTP gateway in RPC-gateway mode);
• all hosts (web, and later mobile over uniffi) get identical submission behaviour, because the logic lives in the shared core instead of each host.

Ownership: before vs after

The topology is unchanged (the core still reaches the network only through the host).
What changes is ownership.
Before, the secret bytes were core-owned but the capability to use them, and the decision of what gets signed, was host-owned:

BEFORE
         core-owned  (WASM worker)          host-owned  (JS main thread)
  +------------------------------+   ||   +------------------------------+
  | Rust core                    |   ||   | dotli (PAPI)                 |
  |                              |   ||   |                              |
  | owns:                        |   ||   | owns:                        |
  |  - allowance secret (64 B)   |   ||   |  - signer handle             |
  |  - sign() execution          |   ||   |     { publicKey, sign() }    |
  |                              |   ||   |  - tx builder (PAPI)         |
  |                              |   ||   |  - decides WHAT is signed    |
  |                              |   ||   |  - submission + watch        |
  +------------------------------+   ||   +------------------------------+

               core --[ signer handle ]--> host   (a live signing capability)
               core <--[ sign(payload) ]-- host   (one request per tx)
               core --[ signature      ]--> host --> Bulletin

After, everything signing-related sits on the core side; during submission the host just forwards opaque JSON-RPC text:

AFTER
         core-owned  (WASM worker)          host-owned  (JS main thread)
  +------------------------------+   ||   +------------------------------+
  | Rust core                    |   ||   | dotli                        |
  |                              |   ||   |                              |
  | owns:                        |   ||   | owns:                        |
  |  - allowance secret (64 B)   |   ||   |  - permission/confirm modals |
  |  - signer (crate-private,    |   ||   |  - chain.connect JSON-RPC    |
  |     never exported)          |   ||   |     pipe (forwards verbatim) |
  |  - tx builder (subxt)        |   ||   |  - lookupPreimage backend    |
  |  - decides WHAT is signed    |   ||   |     (bitswap / IPFS gateway) |
  |  - submission + watch        |   ||   |                              |
  +------------------------------+   ||   +------------------------------+

               core --[ JSON-RPC request  ]--> host --> Bulletin
               core <--[ JSON-RPC response ]-- host
               Bulletin pipe: opaque JSON-RPC text only,
               no signing capability, no sign requests

Submit flow

 PRODUCT  | CORE (holds keys, builds+signs)    : HOST (modals+pipe) : NET
 ---------+------------------------------------+--------------------+---
 submit   > receive                            :                    :
          | remotePermission                   > prompt user        :
          | confirmUserAction                  > prompt user        :
          | allowanceKey (cached, else SSO     :                    :
          |   via People statement store)      > fwd (E2E encrypted)> wlt
          | slotAccountKey (ciphertext)        < forward            < wlt
          | [[ 64-B key decrypted in core ]]   :                    :
          | chain.connect(bulletin)            > open pipe          :
          | chainHead_v1_follow                > forward            > N
          | Metadata_metadata_at_version *     > forward            > N
          | chainHead_v1_header (mortality)    > forward            > N
          | AccountNonceApi_account_nonce *    > forward            > N
          | [[ build + SIGN store(value) ]]    :                    :
          | TaggedTransactionQueue_            :                    :
          |   validate_transaction * (dry-run) > forward            > N
          | transaction_v1_broadcast           > forward            > N
          | watch: nonce probe * per block,    :                    :
          |   chainHead_v1_body on advance     > forward            > N
          | chainHead_v1_storage(Events)       > forward            > N
       key< return blake2_256(value)           :                    :

 * runtime calls, carried on the wire as chainHead_v1_call

Changed surface

• host_logic/extrinsic.rs: offline subxt assembler (config-pinned SubstrateConfig, sr25519 signer, metadata / validity / events / header decoders).
• host_logic/bulletin.rs: store{data} build + sign; the call is resolved by name from the fetched metadata, with a hard check that the data argument really is a byte sequence.
• runtime/bulletin_rpc.rs: the submit flow above + typed errors.
• runtime.rs: Preimage::submit ordering with one allowance refresh + retry on rejection; lookup_subscribe cache + integrity check.
• truapi-platform: PreimageHost keeps only lookupPreimage; BulletinAllowanceKey zeroized on drop; host configs require the Bulletin genesis hash (runtimeConfig.bulletin.genesisHash on the TS side).
• Host TS (@parity/truapi-host) + dotli submodule: signer bridge removed; dotli keeps content lookup only (smoldot bitswap_v1_get, or IPFS gateway in RPC-gateway mode) and serves Bulletin chain.connect on both its light-client and RPC-gateway backends.

[valentinfernandez1]

Overall looks good to me just some small nits.