fix(gui): report macOS phys_footprint in status-bar memory (#3197)

[VU3ESV]

Summary

Fixes #3197 — on macOS the status-bar Mem readout showed ~859 MB while Activity Monitor reported the same process at ~3.19 GB (a ~3.8× understatement).

Two distinct problems with the previous ru_maxrss-based metric on macOS:

1. High-water mark, not current. ru_maxrss monotonically increases over the process lifetime and never reflects pages that were faulted out or compressed.
2. Excludes compressed / IOKit / purgeable pages. Activity Monitor's Memory column uses phys_footprint from task_info(TASK_VM_INFO), which sums anonymous + compressed + IOKit + purgeable. For a Qt/QRhi app with Metal driver state and a long-lived spectrum/waterfall pipeline, the delta is large.

Changes (single file: src/gui/MainWindow.cpp)

• macOS: replace ru_maxrss with task_info(mach_task_self(), TASK_VM_INFO, …).phys_footprint — the exact field Activity Monitor renders, so the two readouts agree by construction.
• Linux (while we're here): switch from ru_maxrss to reading VmRSS: from /proc/self/status so Linux also reports current resident, not the per-process peak.
• Windows: unchanged — WorkingSetSize is already current, not peak.
• Tooltip updated from "AetherSDR process memory (RSS)" to "AetherSDR process physical footprint (matches Activity Monitor)".
• Added mach headers (<mach/mach.h>, <mach/task.h>, <mach/task_info.h>) under Q_OS_MAC.

All three platforms now report a "what the OS sees right now" footprint, matching the unification the reporter asked for under "unifying behind a phys_footprint-style metric on all three platforms."

Out of scope

Whether ~3 GB on an idle single-slice session is itself excessive (waterfall tile retention, FFT history, Metal/QRhi overhead, leaked textures, etc.). That's a separate investigation, well-suited to the per-thread memory trending in the forthcoming System Info diagnostics dialog (#2554). This PR just unblocks the display so any future investigation has a number that matches Activity Monitor.

Test plan

• Local build on Apple Silicon (cmake --build build --target AetherSDR) — compiles clean; only pre-existing -Wdeprecated-this-capture warnings unrelated to this change.
• App launched from the build directory (PID 7857); status-bar Mem value should now track Activity Monitor's Memory column within rounding instead of underreporting by ~3.8×.
• Linux smoke test (/proc/self/status VmRSS path) — not exercised locally; logic is straightforward but a Linux reviewer / CI run is welcome.
• Windows — no code path changed; existing behavior preserved.

Notes for reviewer

• Touches src/gui/MainWindow.{h,cpp} — maintainer-only tier per .github/CODEOWNERS, routing this to @ten9876.
• Triage in macOS: in-app status-bar memory readout (~859 MB) drastically underreports OS-reported footprint (~3.19 GB) for AetherSDR v26.5.3 #3197 by @aethersdr-agent confirmed root cause and proposed exactly this fix.

[jensenpat]

@AetherClaude does the Activity Monitor tooltip show on Windows and Linux?

[aethersdr-agent]

Good catch — yes, it does. The setToolTip(...) call at src/gui/MainWindow.cpp:9102 is unconditional (it sits in buildUI() outside any #ifdef), so Windows and Linux users would see "matches Activity Monitor" in their tooltip even though Activity Monitor is a macOS-only app. That's misleading.

Easiest fix is per-platform tooltip text alongside the per-platform sampling code that's already in this PR:

#if defined(Q_OS_WIN)
    m_memLabel->setToolTip("AetherSDR process working set (matches Task Manager)");
#elif defined(Q_OS_MAC)
    m_memLabel->setToolTip("AetherSDR process physical footprint (matches Activity Monitor)");
#else
    m_memLabel->setToolTip("AetherSDR process resident set (VmRSS from /proc/self/status)");
#endif

Each variant names the metric and the tool a user can cross-check it against on their own OS, which is the whole point of the change in #3197 — having a number that agrees with what the platform's own task viewer shows. The Linux line names the file rather than a specific tool because users there vary widely (System Monitor / htop / btop / etc.) and they all ultimately read VmRSS anyway.

A maintainer can authorize the orchestrator to land this fix by adding the aetherclaude-eligible label.

73, Jeremy KK7GWY & Claude (AI dev partner)

---

_{🤖 aethersdr-agent · cost: $1.1837 · model: claude-opus-4-7}

[VU3ESV]

Fair point — fixed in 70cd355a. The setToolTip(...) is now per-platform, mirroring the per-platform sampling already in this PR:

#if defined(Q_OS_WIN)
    m_memLabel->setToolTip("AetherSDR process working set (matches Task Manager)");
#elif defined(Q_OS_MAC)
    m_memLabel->setToolTip("AetherSDR process physical footprint (matches Activity Monitor)");
#else
    m_memLabel->setToolTip("AetherSDR process resident set (VmRSS from /proc/self/status)");
#endif

Each variant names the metric and the tool a user on that platform can cross-check it against. The Linux line names the kernel-side source file rather than a userspace tool, since users there vary widely (System Monitor / htop / btop / etc.) and they all read VmRSS anyway — matches the spirit of @aethersdr-agent's suggestion verbatim.

Local rebuild on Apple Silicon is clean (no new warnings beyond the pre-existing -Wdeprecated-this-capture noise unrelated to this PR).

[aethersdr-agent]

Confirmed — 70cd355a lands the per-platform tooltip exactly as suggested in the thread, and the surrounding refactor is a nice side-benefit:

• Tooltip strings are now gated by Q_OS_WIN / Q_OS_MAC / else, so each user sees the metric and the platform-native tool they can cross-check against.
• The sampling code was hoisted into a single quint64 memBytes variable with one setText() site, replacing the old nested #ifdef-inside-#ifdef ladder (Linux KB vs. macOS bytes unit handling). One unit conversion path, harder to get wrong next time someone touches it.
• Linux VmRSS: parse looks correct — line.mid(6).trimmed().split(' ').first().toULongLong() * 1024ULL handles the "VmRSS: 12345 kB" format cleanly, including the variable whitespace and trailing kB token.

One tiny nit, not blocking: when memBytes == 0 (e.g. /proc/self/status open failed, or task_info returned non-KERN_SUCCESS), the label keeps its previous text rather than showing "Mem: —". That mirrors the old behavior so it's not a regression, but a future cleanup could fall back to the em-dash so users see "I don't know" instead of a stale value. Definitely a separate change, not this PR's scope.

LGTM from the AetherClaude side — the original #3197 root cause is addressed, the tooltip honesty issue raised by @jensenpat is addressed, and the build is clean on Apple Silicon per the PR description. Linux/Windows CI runs will confirm the other two arms.

73, Jeremy KK7GWY & Claude (AI dev partner)

---

_{🤖 aethersdr-agent · cost: $1.7935 · model: claude-opus-4-7}