fix(makefile): grep cargo tree stdout only in dependency guards

[lxsaah]

The v2.0.0 release workflow (run 35391165477) failed at test-embedded with:

→ Asserting the MQTT dependency is codec-only
✗ the MQTT dependency pulled a driver crate
  Downloaded embedded-hal-nb v1.0.0
  Downloaded embedded-io-async v0.6.1
  Downloaded embassy-embedded-hal v0.6.0

None of those are dependencies of aimdb-mountain-mqtt. Its tree is heapless → hash32 → byteorder plus stable_deref_trait, and the guard passes locally.

Cause

The three dependency-graph guards captured cargo tree with 2>&1 and grepped the result, so cargo's progress output on stderr was searched alongside the tree. Those three "Downloaded …" lines are crates being fetched for later steps, and they match MQTT_DEPENDENCY_FORBIDDEN (embedded-io|embedded-hal|tokio) as plain substrings.

It only fires on a cold cargo cache, which is why it passed locally and in the PR's CI job but broke the release workflow. It would recur on any cold runner.

Fix

Each guard redirects stderr to a temp file instead of folding it into stdout. The "refusing to pass vacuously" behaviour is unchanged — a non-zero exit from cargo still fails loudly, and the captured stderr is printed when it does.

check-no-sim's tree_rand keeps 2>&1 on purpose: it greps for cargo's "did not match any packages" message, which arrives on stderr, and matches an exact phrase that progress lines cannot satisfy.

Verification

make build (guard 1, aimdb-sync no_std)	pass — ✓ no_std graph is free of tokio|libc
make test-embedded (guards 2 and 3)	pass — ✓ embedded MQTT graph is free of …, ✓ mountain-mqtt is the codec alone
stderr noise injected, new form	passes — noise never reaches the grep
stderr noise injected, old form	fails — reproduces the CI failure exactly

The last two matter most: injecting a Downloaded embedded-hal-nb v1.0.0 line reproduces the failure on demand under the old form and passes under the new one, so this is a confirmed cause rather than a plausible one.

Not in scope

The v2.0.0 release itself is unaffected — all 19 crates published successfully, and the tag and GitHub Release are in place. The failed job never reached its "Create GitHub Release" step.

🤖 Generated with Claude Code