sdk: finish and verify the no_std story for the intent-body derive

[mfw78]

From review of #451 (comment 1, comment 2). Confirmed still valid at HEAD. Target: L2 videre (videre-sdk + the no-std-probe).

#451 makes the IntentBody derive emit no ::std paths (verified clean), but the end-to-end no_std goal is neither reached nor verified:

1. The owning crate is still std. videre-sdk (which owns IntentBody / BodyError / __private::alloc; nexum-venue-sdk before the rename) has no #![no_std] attribute at HEAD, and cow-venue and other consumers depend on it unconditionally. #![no_std] on a consumer governs only that crate's own source, not the dependency graph, so a genuine bare-metal build (no std at all, unlike the std-bearing wasm32-wasip2) would fail at videre-sdk's own compilation.
2. No bare-metal target is actually built. The only target config is wasm32-wasip2 (std-bearing); there is no CI job or just recipe building a real no-std triple (e.g. thumbv7em-none-eabi). "Unblocks bare-metal consumers" is checked only by cargo check on the host target, where std is always available.
3. The no-std-probe proves expansion, not correctness. It derives IntentBody on ProbeBody but never calls to_bytes / from_bytes, so it proves the macro expands under #![no_std], not that the generated round-trip logic is correct.

Change

• Convert videre-sdk (the IntentBody owner) to #![no_std] + alloc, if feasible, so the dependency graph is genuinely no_std-capable.
• Add a real bare-metal target build gate: a just recipe plus a CI job running cargo check --target thumbv7em-none-eabi (or similar) over the no_std crates / the no-std-probe.
• Strengthen the no-std-probe with a #[cfg(test)] mod tests block exercising an actual encode/decode round-trip (tests are exempt from the crate's #![no_std], per the cow-venue pattern).

Alternative

If bare-metal is not a real target for this SDK (shepherd's modules run on the std-bearing wasm32-wasip2), scope the no_std claim down to "the derive no longer hardcodes ::std paths" and drop the bare-metal framing.

Acceptance criteria

• Either a real no-std triple builds the intent-body path in CI, or the claim is explicitly scoped to derive-hygiene only.
• The no-std-probe exercises an encode/decode round-trip, not just expansion.

[mfw78]

Landed via #571 (squash-merged into dev/m1 as bd7fbf7). Closing manually since the merge target is not the default branch.