feat(runtime): route nexum:intent/pool to installed venue adapters

[mfw78]

What

Adds the host-side implementation of nexum:intent/pool, the strategy-facing import that routes a module's pool::submit(venue, body) call to the one installed venue adapter for that venue and drives a fixed sequence against it: quota gate, derive-header, guard interposition seam, submit.

• host/pool_router.rs: the PoolRouter. Resolves a venue id to an installed adapter (unknown venue maps to venue-error::unknown-venue), serialises calls per adapter via a tokio async mutex held across the guest await (one venue's calls queue, different venues run in parallel; a trap projects to internal-error instead of unwinding into the caller's store), runs a GuardPolicy interposition seam on the adapter-derived header between derive-header and submit (the shipped AllowAllGuard is a no-op; PoolRouterBuilder::with_guard is the seam the egress-guard work hooks into), and enforces a per-caller submission quota (PoolQuota, default 256 charges / 60s sliding window) that also charges decode failures, so a caller feeding garbage exhausts its own budget rather than the adapter's.
• host/impls/pool.rs, host/impls/mod.rs, host/mod.rs: wire pool in as a host binding linked into every module linker, delegating to a shared, cheaply cloneable PoolRouter carried in each store's HostState (host/state.rs).
• bindings.rs, engine_config.rs: bindgen the pool_host world, reusing venue_adapter's type modules via with so there is no lift between two structurally identical copies of SubmitOutcome/VenueError (no new or modified WIT packages).
• manifest/capabilities.rs: wire the pool-related capability.
• supervisor.rs: rework around the new router plumbing.

Why

The pool world is the strategy-facing entry point for submitting intents; without a router bound host-side a module has no way to reach an installed venue adapter. Centralising venue resolution, serialisation, the guard seam and the quota in one router keeps that policy off individual adapters and gives the egress-guard work a single seam (with_guard) to hook into later.

Testing

• cargo fmt --all -- --check
• cargo clippy -p nexum-runtime --all-targets -- -D warnings (after cargo clean -p nexum-runtime)
• cargo test -p nexum-runtime (229 tests pass; the concurrency/serialisation determinism test reran deterministically 5x)
• cargo test --workspace (only nexum-runtime touched; no wasm modules or WIT packages changed, so no wasm build/clippy/bindgen-smoke gates apply)

AI Assistance

Claude (Opus) used for the implementation.

Closes #229

[lgahdl]

Well-structured router with good test coverage. Three items below.

[lgahdl]

Guard-deny doesn't charge the caller, so a module that the guard blocks can call submit in a tight loop indefinitely. Each iteration passes quota_admits, acquires the adapter mutex, runs derive_header (a full WASM guest call), and then the guard denies — but quota is never consumed. The adapter stays occupied for the duration of each derive call, blocking every other caller to the same venue.

The existing decode_failures_are_charged_and_stop_re_invoking_the_adapter test shows the pattern; the guard-deny path needs the same treatment:

Suggested change

	if let GuardVerdict::Deny(reason) = self.inner.guard.check(&ctx) {
	return Err(VenueError::Denied(reason));
	}
	if let GuardVerdict::Deny(reason) = self.inner.guard.check(&ctx) {
	self.charge(caller);
	return Err(VenueError::Denied(reason));
	}

[lgahdl]

check is synchronous, but the egress-guard epic's real policy will need async calls — oracle price lookups, on-chain allowlist reads, facts-provider queries. Making the trait async now is a cheap one-line change; making it async after the egress-guard epic is underway is a breaking change under delivery pressure.

Suggested change

	fn check(&self, ctx: &GuardContext<'_>) -> GuardVerdict;
	fn check<'a>(&'a self, ctx: &'a GuardContext<'_>) -> futures::future::BoxFuture<'a, GuardVerdict>;

AllowAllGuard::check becomes Box::pin(async move { GuardVerdict::Allow }), and the call site awaits it.

[lgahdl]

"Read-only" is inaccurate — the function mutates the ledger: entry(...).or_default() inserts a new VecDeque for first-time callers, and prune() removes expired entries. The parenthetical even admits to pruning.

Suggested change

	/// Whether `caller` has budget left in the current window. Read-only: it
	/// prunes aged charges but does not record one.
	/// Whether `caller` has budget left in the current window. Does not
	/// record a charge — prunes expired entries to get an accurate count.