fix: refuse component reads when no app is connected

[boorad]

Summary

devtools errors prints No components with errors or warnings with nothing attached. The tree is empty because no app is connected, not because nothing matched, so a check that was never performed renders identically to a check that passed. For an agent reading command output as evidence that is worse than an error, because a vacuous pass propagates into whatever it reports.

$ devtools status
Apps: 0 connected, 0 components
$ devtools errors
No components with errors or warnings          # exit 0, before
No app is connected, so there is no component tree to read. Run `devtools status` ...   # exit 1, after

get tree, get component, find, count and errors now return { ok: false, code: 'NO_APP_CONNECTED' } when nothing is attached. Connection health is read in the same synchronous turn as the tree, so nothing can attach or detach between the check and the answer, and code is machine-readable so callers need not match on message text. cli.ts needed no change: every read already exits non-zero on ok: false.

Profiling commands are deliberately untouched, since they read captured session data that legitimately outlives the app that produced it.

Two behavior changes worth calling out:

• get tree used to attach a disconnected Ns ago, waiting for reconnect... hint to an empty success. That context now qualifies the refusal instead, where it is actionable rather than decorating an answer that looked fine. connection-health.test.ts is updated to match.
• Two daemon-auto-restart tests used get tree only to route a command through ensureDaemon. They now assert the refusal alongside the restart they are actually about; status cannot substitute, because it bypasses ensureDaemon entirely.

Context

Found while using this package through agent-device, which passes these commands through 1:1 — reported as callstack/agent-device#2430. I first gated it in that wrapper by probing status before each read; @thymikee correctly rejected that: a separate probe cannot guarantee the later read observed an app, since the app can disconnect in between, and an unparseable status lets the original vacuous result through. Checking inside the operation that reads the tree is his suggestion, and it is the right one. Reported independently by a second user on RN 0.87.1, where nothing ever attaches, so every errors result was vacuous.

Validation

bun run test 125 pass, bun run test:e2e 42 pass, typecheck and lint clean, build succeeds.

New component-read-attachment.test.ts covers each read refusing with no app ever connected, a read issued after the app disconnected refusing rather than answering from the stale tree, all reads still answering while attached, and status staying answerable throughout. Each new assertion was verified to fail with the daemon guard reverted (7 of them go red), so none of them pass vacuously.

Also exercised against the built CLI: errors and find against a live daemon with nothing attached both print the refusal and exit 1.