Silent produce-error drops in Embassy join handlers

[lxsaah]

Context

The transform_join task model in aimdb-core/src/transform/join.rs and the demos that use it discard the Result returned by Producer::produce:

let _ = producer.produce(DewPoint { celsius, timestamp }).await;

On Tokio and WASM this is mostly fine: when the output record's subscribers all exit, the channel close eventually surfaces and the warm side of the pipeline winds down.

On Embassy this is not fine: the join trigger loop is infinite (Embassy channels do not close), so a chronic produce failure — output buffer exhausted, all subscribers gone, serializer rejecting the value — is silent without tracing. The device keeps spinning with no indication anything is wrong.

Question / design call

Should run_join_transform (and ideally the demo handlers) log produce failures via defmt::warn! in the no-tracing path, mirroring the SPMC subscriber-slot exhaustion pattern that was added in aimdb-embassy-adapter/src/buffer.rs?

Trade-offs:

• For: Closes a real observability gap on Embassy. Matches the SPMC-slot diagnostic precedent. Cheap — defmt::warn! is essentially free when no probe is attached.
• Against: Could be log-spammy if a downstream is genuinely closed. Maybe rate-limit, or only log once per failure-mode transition. Also: should the join transform escalate (exit the loop, panic) on persistent failure? That's a bigger question.

Scope

This issue is about the design call, not just the mechanical change. Worth nailing down:

1. Log on every failure, or once-per-transition?
2. Should there be an escalation path (e.g., exit the loop after N consecutive failures)?
3. Same question applies to run_single_transform — should it be consistent?

Background

Introduced/surfaced during #73. The pattern is in aimdb-core/src/transform/join.rs and the three weather-station demos.