status prints a spurious '[ERROR] rigforge aborted' to stderr when the worker API is unreachable (exit code is still 0)

[VijitSingh97]

Found while working #353 (not a regression from it — reproduces on origin/develop before and after that branch).

rigforge.sh status (and likely tune/autotune, which reach the API through the same propagate-mode reader) prints a duplicate [ERROR] rigforge aborted while running '...' line to stderr when the worker API is genuinely unreachable — even though the command completes correctly, prints its proper fallback message, and exits 0.

Why it matters: the ERR-trap line is the signal operators are taught to treat as "something broke". Emitting it on a handled, exit-0 path trains people to ignore it — and it is exactly the noise that made #341's real abort easy to miss.

Repro: stop the miner (or point api_port at a closed port) and run sudo ./rigforge.sh status; observe the correct "API unreachable" fallback output, exit 0, and the stray [ERROR] rigforge aborted ... on stderr.

Likely shape: a guarded call whose failure still trips the ERR trap because the guard is outside the $(...), or a trap firing on the subshell — the repo's existing "guarded-inside-$()" idiom (#210) is the pattern to apply.

[VijitSingh97]

Fix up in #366. One correction to the framing here, because the title undersells it.

Your "likely shape" guess was right — a guard outside the $(...) while the trap fires inside it —
but the spurious-stderr symptom turns out to be the milder face of the defect, and it is
bash-version-dependent:

• bash 3.2 (macOS) does not carry a caller's suppressed-errexit context (( ... ) || true) into
  a command substitution, so the ERR trap fires inside it. That is the status repro in this issue —
  two lines, correct output, exit 0.
• bash 5.2 (the rigs and the appliance) does carry it, so status is silent there. I could not
  reproduce this issue on miner-0 or the HP appliance at all.

But on every bash, any caller that was not guarded aborted outright. Measured on miner-0 and
the HP ProBook appliance with the API refusing connections: tune/autotune's sampling loop and a
bare _status_api_summary both died with [ERROR] rigforge aborted ... (exit 7). So an API that
went away mid-sweep — the miner restarting under you — took the sweep with it. That is the
fleet-relevant bug, and it is the same root cause as the noise you saw.

Also worth recording: the trap fires once per stack frame, not twice for one command — once for the
failing curl inside _read_api_summary, then again as that function returns 7 (curl is its last
command) one frame up in _status_api_summary. Hence exactly two lines.

Fix is at the readers rather than the call sites: the propagate mode had no consumer (every caller
branches on an empty body, none read the status), so it is deleted and both readers now always return
0 with an empty body. That retires #210's guard-inside-the-$( ) idiom for these readers instead of
spreading it further. set +e in svc_status's subshell was tried and does not work — bash's ERR
trap fires independently of errexit.