[gersham]

Sequencing

Do not merge yet. This waits behind the Caddy-orphan activate.sh fix on
screenrig/backend. Nothing in this PR depends on backend code — the change is
local host probing — but the merge order is held deliberately. No deploy, no
npm publish, no plugin bundle change, and no production ingest is part of it.

The regression

screenrig doctor --json against production returned a valid success envelope
and still exited 1 on a clean machine, because the cwebp row was a fail.

doctor gave every check a binary pass/fail and exited non-zero whenever
any row was not a pass. cwebp is only the fallback the image planner uses
when the ffmpeg build has no libwebp encoder (src/media/transcode.ts), so a
host whose ffmpeg carries libwebp — the ordinary prod/dev machine — failed
doctor over a binary the CLI never runs there. encoder_libx265
(--codec hevc only), filter_hdr_tonemap (documented warn-and-fallback), and
the server-advertised feedback feature had the same false-failure shape.

The change

Checks now carry pass, warn, or fail, and only a fail moves the exit
code, so a host missing nothing required exits 0.

Row	Before	Now
cwebp, ffmpeg has libwebp	fail	warn: not required because this ffmpeg build has the libwebp encoder
cwebp, ffmpeg has no libwebp	fail	fail, naming ffmpeg-with-libwebp, cwebp on PATH, or SCREENRIG_CWEBP
encoder_libwebp, cwebp usable	fail	warn (stills transcode through the fallback; animation does not)
encoder_libwebp, no cwebp	fail	fail
encoder_libx265	fail	warn: --codec hevc is unavailable
filter_hdr_tonemap	fail	warn
feedback	fail	warn
encoder_libx264	fail	fail (the default video profile)

node, config_permissions, token, api_url, ffmpeg, ffprobe, and the
four control-plane rows keep failing. encoder_libwebp and cwebp are the two
ways to produce the one delivery format for images, so they fail together in
the one case that is a genuine defect: the host has neither and no image can be
transcoded. The encoder_libwebp detail still describes the ffmpeg encoder
alone and never implies the fallback covers it.

The envelope gains data.status, the worst row in the list, so an agent can
branch without scanning the rows. Stdout stays a success envelope, as before.

cwebp remains a host dependency: neither the plugin launcher nor the npm
package installs ffmpeg, ffprobe, or cwebp, and the new README section says so
alongside the PATH / SCREENRIG_CWEBP resolution order.

Evidence

Real host in this run (ffmpeg 6.1.1 with libwebp, no cwebp binary), which is
exactly the reported configuration:

PASS ffmpeg: ffmpeg 6.1.1-3ubuntu5
PASS encoder_libx264: libx264 available
PASS encoder_libx265: libx265 available
PASS encoder_libwebp: libwebp available
PASS filter_hdr_tonemap: zscale and tonemap available
WARN cwebp: cwebp not available; not required because this ffmpeg build has the libwebp encoder

npm run smoke:mock on that same host now runs doctor end to end through
dist/bin.js and asserts exit 0 when no check failed, plus that cwebp is
never a fail while encoder_libwebp passes.

Four new unit tests cover the matrix (clean host without cwebp, optional
encoder/filter warnings, libwebp missing with cwebp present, and neither
present). Checked out against the pre-fix src/commands.ts, the clean-host test
fails as the reported bug and passes after the change.

Gates run from this checkout: npm ci, check:public, vendor:check,
typecheck, lint, test (346 tests, 0 failures), smoke:mock, pack:dry,
pack:release, check:npm-install — all pass. No vendored file changed.
smoke:server was not run (needs an owned local backend) and neither was
vendor:check:drift (needs a backend checkout). Nothing here proves playback
on player hardware or in production.

Not in this PR

No deploy, no publish, no plugin bundle change. The plugin picks this up when it
pins a newer CLI artifact.