sdk: make the IntentBody derive no_std

[mfw78]

What

Rewrites the #[derive(IntentBody)] codegen in nexum-macros to emit ::core/::alloc paths (via a new nexum_venue_sdk::body::__private::alloc re-export) instead of ::std. Flips cow-venue to #![no_std] (tests aside) and adds a no-std-probe workspace crate that derives IntentBody under #![no_std] with no extern crate alloc of its own.

Why

The derive's generated code named ::std, so any consumer linked std and could never be a genuine #![no_std] crate, breaking the no_std contract the venue body slice documents. Guest wasm targets tolerated it (wasip2 is std-bearing) but it blocked bare-metal consumers.

Testing

• no-std-probe crate compiles #![no_std] against the derive (workspace check/clippy gate covers it going forward).
• cow-venue builds #![no_std] outside test cfg.

Closes #322

AI Assistance

Implemented with Claude Code assistance; reviewed and tested by a human.

[lgahdl]

The macro codegen rewrite itself is clean — checked the full intent_body.rs at the head commit and there's no straggler ::std path anywhere in the file, and the __private::alloc re-export follows the standard serde-style macro-hygiene pattern. One thing worth verifying before treating this as done, though:

[lgahdl]

Checked the actual owning crate of IntentBody/BodyError/__private::alloc — nexum-venue-sdk's lib.rs has no #![no_std] attribute anywhere (confirmed at this PR's head commit); it's a regular std crate. cow-venue depends on it unconditionally for the body feature. #![no_std] on cow-venue only governs this crate's own prelude/source, it doesn't make the dependency graph no_std-capable — building for a genuine bare-metal target (no std implementation at all, unlike wasm32-wasip2 which the PR body itself notes is "std-bearing") would almost certainly fail at nexum-venue-sdk's own compilation step, before cow-venue is even reached. The repo's only specialized target config (.cargo/config.toml) is wasm32-wasip2, and there's no CI job or just recipe building against an actual no-std-only target triple (e.g. thumbv7em-none-eabi) — so the stated goal ("blocked bare-metal consumers" → unblocked) is checked only by cargo check on the default host target, where std is trivially available regardless of any #![no_std] attribute. Worth either converting nexum-venue-sdk itself to #![no_std] (if that's feasible), or scoping the PR's claim down to "the derive no longer hardcodes ::std paths" rather than "unblocks bare-metal consumers," since that part is unverified and likely not yet true.

[mfw78]

Confirmed still valid at HEAD. videre-sdk (the IntentBody owner post-rename) still carries no #![no_std] at the tip, and there is no CI/just build against a real no-std triple - only wasm32-wasip2 (std-bearing) and host cargo check. The derive itself is clean; the bare-metal goal is unverified and, per the unconditional videre-sdk dependency, not yet reachable. Tracked in #521, with your scope-down alternative recorded there.

[lgahdl]

Relatedly: this direct dependency on nexum-venue-sdk is exactly the path through which a genuine no-std-target build would fail (see the cow-venue/lib.rs:28 comment) — the probe only proves the derive macro's generated code doesn't reference ::std textually, not that the crate graph can target a real bare-metal platform. Also, separately: the probe only derives IntentBody on ProbeBody, it never calls to_bytes/from_bytes — so it proves macro expansion under no_std, not correctness of the generated round-trip logic. A #[cfg(test)] mod tests block (tests are exempted from the no_std attribute per the cow-venue pattern) exercising an actual encode/decode round-trip would close that gap cheaply.

[mfw78]

Confirmed still valid at HEAD - the no-std-probe at the tip still only derives IntentBody without a round-trip. A #[cfg(test)] encode/decode test (exempt from #![no_std], per the cow-venue pattern) would prove the generated logic, not just expansion. Folded into #521.