feat(venue): admit the logging capability to the venue-adapter world

[mfw78]

What

Admits the logging capability to the venue-adapter world: VENUE_CAPABILITIES in crates/videre-macros/src/world.rs now includes logging alongside chain, messaging, and http, and synthesize_venue threads the capability's adapter ident through so the #[venue] macro (crates/videre-macros/src/lib.rs) can emit an install_tracing() glue function when logging is declared, wiring the guest nexum_sdk::tracing facade and panic hook onto the world's nexum:host/logging import via a LogSink impl - the function only exists when the capability is declared, so the facade cannot bind to an undeclared import. videre-sdk re-exports nexum_sdk (crates/videre-sdk/src/lib.rs) so the macro-emitted glue reaches it without adding a direct dependency in adapter crates. VenueAdapterKind::link in crates/videre-host/src/registry.rs binds nexum::host::logging::add_to_linker unconditionally alongside chain and messaging, gated per adapter by the declared world same as the other two. The new fixture crate modules/fixtures/logging-venue declares logging alone in module.toml and exercises install_tracing, an INFO/WARN event with structured fields, and a per-level probe from init, plus one INFO event from a dispatched verb. crates/videre-host/tests/platform.rs adds e2e_logging_venue_component_imports_logging_when_declared (the component imports nexum:host/logging and nothing else capability-bearing), e2e_logging_adapter_tracing_reaches_the_host_pipeline (host-interface records preserve each event's own level and its rendered fields, boot-time and verb-interior), and e2e_undeclared_logging_import_refuses_the_adapter_at_boot (an adapter manifest omitting logging from required is refused at boot). The positive E2E now boots the fixture from modules/fixtures/logging-venue/module.toml (logging already in [capabilities].required) instead of a tempdir synthetic manifest, and the placeholder component = "sha256:0000..." line is gone from module.toml and the inline test manifests since the pin now rejects the all-zero digest sentinel at parse.

Why

The venue-adapter world previously withheld logging along with the store and identity capabilities, leaving venue adapters with no host-backed way to emit diagnostic records; logging grants no authority beyond emitting records the host already accepts from every module world, so refusing it bought no isolation while forcing adapter authors toward ad hoc workarounds. Wiring the standard nexum_sdk::tracing facade through the macro keeps venue adapters on the same guest-side logging idiom as core modules instead of a bespoke shim.

Closes #26

Testing

All runs in the repo's pinned nix develop shell (rustc 1.94.0, cargo-nextest 0.9.127), on a fresh clone detached at fb3e434 (identical to origin/feat/venue-logging-capability); origin/feat/denial-classification-seam confirmed an ancestor of HEAD.

• cargo clippy -p videre-host -p videre-macros -p videre-sdk --all-targets --all-features -- -D warnings - clean.
• cargo clippy --workspace --all-targets --all-features --locked -- -D warnings (CI's exact clippy job; covers the new logging-venue member on the native target) - clean.
• cargo fmt --all -- --check - clean.
• cargo test --doc -p videre-host -p videre-macros -p videre-sdk --all-features - ok (0 doctests in each of the three).
• Red-teamed by re-deriving the diff and mutating the code rather than trusting the report: the world synthesis, the linker addition, and the guest glue are correct, no venue-specific symbol enters videre-sdk/host/macros, no new dependency beyond the fixture's tracing (matching the upstream guest idiom and an existing workspace dep), no em-dashes and no new banner comments, the "unchanged when not declared" done-when is covered by the pre-existing echo-venue import test, and the wasm build is clean.

AI Assistance

Implemented with claude-fable-5, red-teamed with claude-opus-5, PR description written with claude-sonnet-5.

[mfw78]

Adoption blocker filed upstream: nullislabs/nexum-runtime#77. The pinned runtime rejects logging in a provider manifest (PROVIDER_CAPABILITIES is chain+messaging only), so this PR is safe to merge but no adapter can declare the capability until the runtime admits it. The same issue carries the target-field gap: the WIT log verb has no target, so "level and target intact" needs an additive WIT change or a documented limitation.

[mfw78]

Correction: the canonical upstream issue for the provider logging capability is nullislabs/nexum-runtime#76 (filed during implementation; also covers declaration enforcement). nexum-runtime#77 was a duplicate and is closed.