feat(truapi-server): add host logic primitives

[pgherveou]

Adds the host-agnostic truapi-server logic primitives for session state, permissions, product accounts, SSO pairing/messages, dotns routing, and statement-store handling.

---

Stack

Part of the Rust core runtime port (umbrella: #104), split into a reviewable stack. Merge bottom-up.

1. feat(truapi): add testing API and versioned wiring #248 — truapi: testing API + versioned wiring
2. feat(truapi-platform): add host capability traits #249 — truapi-platform: host capability traits
3. feat(truapi-codegen): emit Rust dispatcher, wire table, and host callbacks #254 — truapi-codegen: Rust dispatcher + wire table
4. feat(truapi-server): add host logic primitives #255 — truapi-server: host logic primitives 👈
5. feat(truapi-server): add wire and chain infrastructure #256 — truapi-server: wire and chain infrastructure
6. feat(truapi-server): add platform runtime and host bridge #250 — truapi-server: platform runtime and host bridge
7. feat(host-wasm): add @parity/truapi-host-wasm runtime #252 — host-wasm: @parity/truapi-host-wasm runtime
8. chore: docs, CI, tooling, and dotli integration for the Rust core #253 — docs, CI, tooling, dotli integration

Local verification

• cargo build --workspace --all-targets --all-features
• cargo +nightly fmt --check
• cargo +nightly clippy --workspace --all-targets --all-features -- -D warnings
• cargo test --workspace --all-features

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	cargo/​web-sys@​0.3.98
	cargo/​thiserror@​1.0.69
	cargo/​wasm-bindgen@​0.2.121
	cargo/​subxt-rpcs@​0.50.1
	cargo/​blake2-rfc@​0.2.18
	cargo/​console_error_panic_hook@​0.1.7
	cargo/​send_wrapper@​0.6.0
	cargo/​sp-crypto-hashing@​0.1.0
	cargo/​aes-gcm@​0.10.3
	cargo/​bs58@​0.5.1
	cargo/​futures-timer@​3.0.3
	cargo/​hkdf@​0.12.4
	cargo/​p256@​0.13.2
	cargo/​pin-project@​1.1.13
	cargo/​primitive-types@​0.13.1
	cargo/​schnorrkel@​0.11.5
	cargo/​sha2@​0.10.9
	cargo/​tracing@​0.1.44
	cargo/​tracing-subscriber@​0.3.23
	cargo/​wasm-bindgen-futures@​0.4.71
	cargo/​wasm-bindgen-test@​0.3.71
	cargo/​web-time@​1.1.0
	cargo/​getrandom@​0.4.3 ⏵ 0.2.17	+20
	cargo/​js-sys@​0.3.98
	cargo/​unicode-normalization@​0.1.25

View full report

[replghost]

Boundary question before this layer settles: #254 looks like protocol/runtime mechanics, but this PR makes truapi-server start owning reusable host SDK behavior.

The concern is mostly architectural, not a correctness nit. host_logic.rs says the core owns the canonical implementation for everything outside platform syscalls, and the modules here include product account derivation, product entropy, permission grant caching, statement-store signing/proof helpers, SSO pairing/session material, and People identity parsing. Those overlap with existing useragent-kit modules and public SDK surfaces: useragent-wallet derivation/pairing, useragent-sso, useragent-encoding / useragent-chain statement-store code, useragent-product-view permissions, and the Swift/Android/JS wrappers already consumed downstream.

If the intended architecture is that useragent-kit becomes the modular host-building toolkit while TrUAPI remains the protocol/dispatcher/conformance source of truth, I think this PR should either:

1. keep only protocol/runtime-neutral primitives in truapi-server and move host capability implementations into useragent-kit, or
2. explicitly mark these modules as temporary/reference/dotli integration code with a follow-up to re-home reusable host logic before mobile/app integrations build on it.

That would let the stack land without locking us into two competing host SDKs. The app migration path can then be: generated TrUAPI dispatcher -> useragent-kit implementation -> platform callbacks only for UI/storage/permissions/navigation.

[pgherveou]

@replghost
agreed we should do 1 or 2 - let me see what it would take.

1. keep only protocol/runtime-neutral primitives in truapi-server and move host capability implementations into useragent-kit, or
2. explicitly mark these modules as temporary/reference/dotli integration code with a follow-up to re-home reusable host logic before mobile/app integrations build on it.

That would let the stack land without locking us into two competing host SDKs. The app migration path can then be: generated TrUAPI dispatcher -> useragent-kit implementation -> platform callbacks only for UI/storage/permissions/navigation.

[valentinfernandez1]

Just small nit about versioned enums but aside from that this PR looks solid

[valentinfernandez1]

Is the plan for versioning here to expand the RemoteMessageData enum with new versions as new messages are needed?

Would be a good thing to have this documented

[valentinfernandez1]

Same here, would be good to have documentation on what should be the process for adding new versions