fix(api): an unreachable worker API must not abort the run, or cry abort while succeeding (#364)

[VijitSingh97]

Closes #364.

Not just noise — it aborted runs on the rigs

#364 is filed as spurious stderr on an exit-0 path, and that is real. But tracing it turned up a
worse sibling on the same root cause, and that one bites on hardware rather than a dev laptop:
an unreachable worker API aborted tune/autotune's sampling loop outright. A miner restarting
under a sweep took the sweep with it. Please don't read this as cosmetic.

Root cause

The API readers had a propagate mode that let curl's exit escape, so an unreachable miner would
"surface upstream". Nothing upstream ever read that status — every caller branches on an empty
body. Letting it escape then broke two ways depending on the bash running the script:

	bash 5.2 (rigs, appliance)	bash 3.2 (macOS)
Caller not guarded (tune/autotune sampling)	aborts, exit 7	aborts, exit 7
Caller guarded with ( ... ) || true (status)	quiet	prints the abort banner twice

set -E inherits the ERR trap into the $( ) each caller reads through. Bash 3.2 does not carry
the caller's suppressed-errexit context into that child, so the trap fires there once per frame the
failure unwinds through — hence two lines from status while it still printed its correct fallback
and exited 0. 5.2 does carry it, which is why this showed up on dev machines and not on the rigs.

The trap fires once per stack frame, not twice for one command: once for the failing curl inside
_read_api_summary, then again as _read_api_summary returns 7 (curl is its last command) one frame
up in _status_api_summary.

Fix

propagate is gone. Both readers always return 0 with an empty body when the API is unreachable —
the contract every caller already assumed — so neither failure shape is reachable. This fixes
status, tune, autotune and the control channel's post-apply liveness wait in one place instead
of copying #210's guard to each call site; the watchdog's || true is removed because the reader now
owns the guarantee.

Two alternatives considered and rejected:

• set +e inside svc_status's subshell — tested, silences nothing: bash's ERR trap fires
  independently of errexit.
• Guard each call site (watchdog: crashes (exit 28) on an unreachable API instead of counting a strike — wedge recovery never fires in v1.5.0 #210's idiom) — leaves every sibling caller broken; the readers are the
  one place all of them route through.

Verification

Old-vs-new, API refusing connections, ERR trap live:

	miner-0 (bash 5.2)	HP ProBook 650 G5 appliance (5.2.37)	macOS (3.2)
before — unguarded read	died, 4 abort lines	died, 4 abort lines	died, 4 abort lines
after	survived, loop completed, 0	survived, loop completed, 0	survived, 0
before — status verb	0 (guard holds)	0 (guard holds)	2 lines (as reported)

• bash tests/run.sh: 1699 passed, 0 failed. make lint + make lint-md clean.
• 7 new assertions, each verified to fail on the pre-fix script (1692/7 against old code) — no
  vacuous coverage. All 10 existing watchdog: crashes (exit 28) on an unreachable API instead of counting a strike — wedge recovery never fires in v1.5.0 #210 assertions still pass, which is what backs removing the
  watchdog guard.
• Bench left as found: reservation lock never taken (tests were read-only and seconds long), temp
  dirs removed, miner-0's xmrig untouched.

Note for the reviewer

The tune-side test is driven as a separate bash process deliberately. Run inside a subshell it
inherits the suite's own errexit context, and since 5.2 and 3.2 disagree about whether that context
crosses into a $( ), it silently disarms the failure under test on one platform or the other. Two
earlier drafts of this test passed against the broken script for exactly that reason. Please don't
fold it back into a subshell.