Reviewed the C++ closely against the current tree. This is clean, well-scoped, and genuinely additive — the per-meter freshness (age_ms) is the right root fix for the "single-instant read catches a stale/zero value" class of meter bug, and the safety rails (watchdog, power ceiling, force-unkey on stop()) are exactly what an agent-drivable TX bridge needs. All six CI checks are green.

Verification I did locally:

• Every new TransmitModel/RadioModel/MeterModel call resolves against main (atuStatus, atuBypass, atuStart, startTwoToneTune, stopTune, setMox, isTuning/isMox/isTransmitting, model(), meterModel(), transmitModel()).
• atuStatusName() covers all 10 ATUStatus enum values — no fallthrough gap.
• packetUpdatedMs referenced in updateValues() is the existing local at line 417; the new m_valueUpdatedMs writes/erases are kept in sync with m_values in removeMeter()/clear(). ✅
• Null-handling is consistent: doGet checks radio, and doTxTest/doAtu/forceUnkey/onTxWatchdog all guard m_radioModel.

Two small, non-blocking robustness notes:

1. Watchdog re-arms after a force-unkey. forceUnkey() resets m_txKeyedSinceMs = 0, so if the radio somehow stays keyed (stopTune/setMox didn't take), the next watchdog tick sees keyed && m_txKeyedSinceMs == 0, re-arms from now, and grants a fresh full m_txMaxKeyMs window before it would try again — i.e. the backstop fires once every ~20 s rather than continuously while still keyed. In practice the unkey should take effect immediately so the risk is low, but for a true last-resort backstop you might prefer to keep issuing the unkey each tick while still-keyed-past-limit (e.g. latch "limit exceeded" instead of resetting the start timestamp in forceUnkey).

2. Misconfigured env can silently disable TX. qEnvironmentVariableIntValue returns 0 for an empty or non-numeric value, so AETHER_AUTOMATION_TX_MAX_MS= (or a typo) sets m_txMaxKeyMs = 0, which force-unkeys on the first watchdog tick of any transmit; AETHER_AUTOMATION_TX_MAX_POWER=0 likewise clamps all power to 0. Consider only overriding the defaults when the parsed value is > 0:

bool ok = false;
const int ms = qEnvironmentVariableIntValue("AETHER_AUTOMATION_TX_MAX_MS", &ok);
if (ok && ms > 0) m_txMaxKeyMs = ms;

so a bad value fails safe to the default rather than to "never transmit."

Neither is a merge blocker. Nice work, and thanks for the detailed live-verification log on the FLEX-8400M into a dummy load — the PACURRENT reliability annotation (scoped to one explicit entry with a SMART-11281 reference rather than a heuristic) is a good call. 👍

_{🤖 aethersdr-agent · cost: $4.7751 · model: claude-opus-4-8}

Approving (Tier 1 / automation bridge, per AGENTS.md).

TX-keying gating is correct and complete: txtest twotone and atu start (both key TX) are gated behind AETHER_AUTOMATION_ALLOW_TX; txtest off and atu bypass (relay-only) are correctly ungated; the power ceiling, TX watchdog, and force-unkey-on-stop() rails are all ALLOW_TX-armed. These new verbs call startTwoToneTune()/atuStart() directly (bypassing the widget-level aetherTxKeying guard) but carry their own m_txAllowed gate, so the whole keying surface still requires the explicit opt-in.

The age_ms per-meter freshness is the right root fix for the single-instant-stale-read bug class (timestamps kept in sync on removeMeter/clear). Thoroughly hardware-verified on a FLEX-8400M into a dummy load — watchdog fired ~8.5s, power clamp 80/90W→30W, ATU bypass cleaned SWR 1.83→1.15, two-tone drove ALC to −6.4 dBFS, PACURRENT staleness now detectable. CI green on all six; the bot verified the full API surface.

The two robustness items from review are deferred to fast-follow #3743:

1. Watchdog should re-issue the unkey each tick while still keyed-past-limit (today it re-arms a fresh window after forceUnkey resets the timestamp) — narrow edge (only if the radio ignores an unkey; the primary hung-script threat is handled), but worth tightening on a last-resort safety rail.
2. Fail safe to defaults on a misconfigured TX_MAX_MS/TX_MAX_POWER env (both already fail toward not-transmitting — usability nit).

Landing the verified-on-hardware improvement now; #3743 tracks the hardening. Thanks @jensenpat — excellent live-verification log.

Rebased onto current main and pushed (force-with-lease) — head is now a5b5ab6d, MERGEABLE.

The only conflict was AutomationServer.cpp, where this PR and the since-merged #3722 (validation hardening) + #3729 (PACURRENT flag) all added to the same regions. Resolved by keeping all three (they're complementary):

• get model dispatch + the unknown-model error list now include equalizer/eq (#3722), meters (this PR).
• equalizerSnapshot() (#3722) and metersSnapshot() (this PR) coexist; metersSnapshot kept its 2-arg PACURRENT-aware form (unreliableMeterNote(name, radio->model()) annotating the all table with reliable:false+note, from #3729).

Verified locally: full app builds clean (AutomationServer.cpp + MeterModel.cpp compile, link OK), and meter_model_test passes 13/13. Diff vs main is +507/−8 — identical footprint to the pre-rebase PR.

Re-approving (the force-push reset the prior approval). My review verdict is unchanged: TX-keying gating correct and complete, hardware-verified; the two robustness items are tracked in fast-follow #3743. I'll merge once CI goes green.

(Commits are committer-signed by me from the rebase; the squash-merge will be GitHub-signed regardless.)