chore(cli): sweep stale comments, misleading messages, and a tracing stop gap

[0xKT]

Problem

Four small pieces of drift left behind by recent CLI refactors: stale comments, two misleading messages/docstrings, and a tracing lifecycle gap. None is worth its own PR; together they make one clean sweep.

Evidence

1. Stale hard-exit comments. raven/cli/agent_commands.py:404 still says "The exit chokepoint in raven.cli.commands.run hard-exits past finalization when that hazard is live", and raven/cli/agent_commands.py:356 refers to "the hard-exit below", but raven/cli/_exit.py's own docstring states that gate is gone ("That gate is gone: nothing under raven/ imports lancedb") and the only remaining caller is the pytest session hook. Related tests still monkeypatch os._exit as a leftover safety net for that path; harmless, but it documents a mechanism that no longer exists there.
2. Doctor's exit-code docstring omits the invalid-config state. raven/cli/doctor_commands.py:7 lists exit 1 as "static check failed (config missing / schema invalid / unresolved routing)"; the invalid-JSON config state (Config line shows a warning instead of a green check, exit 1) is only implied.
3. Onboard's sandbox skip message can be wrong. raven/cli/onboard_commands.py:2056 prints "Keeping run location: host (direct)." on the skip/non-interactive path even when the persisted sandbox backend is boxlite, i.e. it asserts a state that is not the one being kept.
4. An externally started tracing viewer cannot be stopped. raven/cli/tracing_commands.py:200 reuses a live-and-healthy viewer on the expected port even when there is no pid record (e.g. started by an older raven or by hand), so raven tracing stop cannot manage that instance.

Suggested direction

One small cleanup PR: rewrite the two comments to describe the current shutdown behavior (and drop the residual os._exit monkeypatches if nothing needs them), add the invalid-config wording to the doctor docstring, make the onboard skip message read the persisted backend before claiming what is kept, and for the tracing viewer either discover the pid when adopting an unrecorded instance (lsof/psutil) or print that stop will not manage it.