feat(runtime): introduce the venue-adapter component kind

[mfw78]

What

Introduces the second component kind, the venue adapter, alongside the existing event-module. A venue adapter speaks one venue's protocol only: it imports the scoped nexum:host/chain and nexum:host/messaging interfaces and exports init plus the new nexum:intent/adapter face, and deliberately withholds the core-only primitives (local-store, remote-store, identity, logging) an event-module gets.

• Added the nexum:intent/adapter interface (derive-header/submit/status/cancel), host-independent and using intent types only.
• Added a new nexum:adapter package with a venue-adapter world that imports scoped nexum:host/chain/messaging, exports init plus the adapter face, and withholds local-store/remote-store/identity/logging.
• Version-pinned cross-package WIT references (@0.2.0 / @0.1.0) so the new packages resolve.
• Added a second bindgen path binding VenueAdapter beside EventModule in bindings.rs, reusing nexum:host/{types,chain,messaging} via with so the chain/messaging Host impls and the fault type are shared with event-modules.
• Added a ModuleKind discriminator on [module] in the manifest, defaulting to event-module.
• Added [[adapters]] engine config with per-adapter scoped http_allow and messaging_topics grants, enforced ahead of the messaging backend stub.
• Added an adapter linker that withholds core-only interfaces, and an adapter load path in the supervisor mirroring the module machinery, without dispatch.

Why

Event-modules and venue adapters have different trust boundaries: an adapter should only ever be able to reach the venue it speaks to, never the local-store, remote-store, identity, or logging primitives an event-module gets. Modelling the adapter as its own component kind, with its own capability namespace and its own scoped transport grants in engine.toml, lets the operator (not the adapter author) decide what a venue adapter may reach, instead of relying on the adapter's own manifest to self-limit.

Testing

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace (217 tests pass)
• Bindgen compiles for the new nexum:adapter/nexum:intent/adapter packages (the crate compiling is the bindgen smoke test)

Scope of change is limited to the nexum-runtime crate plus two WIT additions (wit/nexum-adapter/venue-adapter.wit, wit/nexum-intent/adapter.wit); no wasm modules touched, so module-level wasm build/clippy gates are not applicable.

AI Assistance

Claude (Opus) used for the implementation.

Closes #228

[lgahdl]

Solid scaffold for the adapter kind. Three items below.

[lgahdl]

query is not scope-checked. publish enforces topic_in_scope, but query takes _content_topic and returns Ok(vec![]) unconditionally. An adapter with messaging_topics = ["/nexum/1/cow-orders/proto"] can call query on /nexum/99/anything without refusal. This is inert while the backend is deferred, but when the Waku backend lands in 0.3 the scope hole will be live. The enforcement machinery already exists — a one-liner mirrors publish.

Suggested change

	Ok(vec![])
	Ok(vec![])
	// TODO(0.3): enforce topic_in_scope here before the Waku backend lands.

[lgahdl]

"May reach" is inaccurate — only publish is gated; query is unscoped. Mirrors the more precise phrasing on HostState::messaging_topics.

Suggested change

	/// Messaging content topics this adapter may reach.
	/// Messaging content topics this adapter may publish to.

[lgahdl]

When no module.toml exists, fallback_manifest() supplies ModuleKind::EventModule (the #[default]) and this error fires saying the adapter "declares" EventModule — but the adapter declared nothing; it has no manifest. The warn! two lines up says "no module.toml", which correctly diagnoses the situation, but the error that propagates to the caller implies the operator should fix a kind field that doesn't exist yet. Two-branch message:

• No manifest found → "no module.toml found; an [[adapters]] entry requires one with [module] kind = \"venue-adapter\""
• Manifest present but wrong kind → current text ("declares module kind…")

[lgahdl]

The purity claim is convention only. The nexum:adapter/venue-adapter world imports chain and messaging at the world level, making both available to derive-header — WIT has no per-function import restriction. An adapter can call chain.get_block() or messaging.publish() inside derive-header, and those side effects happen before the host runs guard policy (the router calls derive-header first). Before the router lands, document this as a known gap, or restrict derive-header to a sub-world that withholds chain+messaging.

Suggested change

	/// Project an opaque intent body onto the stable header guard policy
	/// runs on. A pure derivation: no transport, no side effects, so the
	/// host can derive and inspect a header before deciding to submit.
	/// Project an opaque intent body onto the stable header guard policy
	/// runs on. Intended as a pure derivation (no transport, no side effects)
	/// so the host can inspect a header before deciding to submit — but the
	/// WIT interface cannot enforce this; enforcement is by adapter-author
	/// convention. The router must assume `derive-header` may call chain or
	/// messaging and account for those side effects in its policy timing.
	derive-header: func(body: list<u8>) -> result<intent-header, venue-error>;