The host cannot obtain session-derived identity material, so adopting core pairing forces a second parallel pairing

[johnthecat]

Problem

The core owns the session and persists it as an opaque blob. The only decoded view is
SessionUiInfo — public_key, identity_account_id, lite_username, full_username
(truapi-platform/src/lib.rs:951-960), all public display values. CoreAdmin (:475-501)
derives nothing from the session.

Polkadot Desktop needs three values that arrive in the same handshake the core already
consumes and discards: the identity X25519 private key (for its P2P chat channel), and
the authorising device's encryption public key and statement account id. There is
no read path for the first at all, and the other two are not in SessionUiInfo.

It gets them today from its own handshake. Adopting core pairing removes that source, so
the only workaround is keeping a second duplicate pairing alive to harvest them — the user
pairs twice, and two sessions exist for one identity.

Possible solving path

Split by sensitivity. The two public values could go on SessionUiInfo as
peer_device_enc_public_key / peer_device_statement_account_id.

The private key could stay core-owned behind a scoped derivation, so the root never leaves
the core:

interface CoreAdmin {
  // ...existing members
  deriveSessionSecret(purpose: { tag: "ChatIdentity" }): Promise<Uint8Array>;
}

A closed purpose enum keeps the core in control of what may be derived and lets each new
host need be reviewed one variant at a time. Any shape yielding the same three values works.

---

Verified against paritytech/truapi@7811017d (published @parity/truapi@0.9.0 / @parity/truapi-host@0.6.0, plus two commits). Citations are Rust source, since the TS host contract is gitignored codegen output.