[🚀 Feature]: [rust] Simplify Selenium Manager output to a single human/application toggle

[titusfortner]

Description

Selenium Manager's --output flag has grown by accretion (logger → json/shell → mixed) into four modes that aren't four distinct use cases — they're two use cases with duplicates, and none of them provides the behavior conventionally expected of a CLI tool:

--output	stdout	stderr	Notes
logger	• result + logs (text) • Streamed	nothing	• Default
shell	• result + INFO logs (text) • Streamed	• logged errors (text) • Streamed	• Not currently used • WARN/DEBUG/TRACE logging completely dropped, always (even with --debug)
json	• result + logs (JSON) • Buffered	nothing	• java, py, rb, js (pending #13989) • A crash can lose all logs • result.message intended as the failure reason, but holds the last non-path INFO/ERROR log, even on success
mixed	• result (JSON) • Buffered	• logs (text) • Streamed	• .NET • error field always holds the last non-path INFO/ERROR log, even on success
Proposed CLI default	• result (text) • Buffered	• logs (text) • Streamed	• Follows standard conventions
Proposed Bindings default	• result (JSON) • Buffered	• logs (JSON) • Streamed	• Follows standard conventions • Error information not included in result but obtained from exit code

I uncovered this issue trying to figure out how to emit a notice about what data is getting sent to Plausible. There is no way to do it that works properly in all the --output modes we support because it conflates concerns that should be independent.

Proposal

Deprecate the --output toggle and replace with an audience target toggle — human vs application — with one consistent discipline underneath:

1. Result → stdout, all diagnostics → stderr, always. Not a per-mode choice.
2. One toggle selects only the payload shape on stdout: human-readable text (default) vs structured (JSON). (logger/shell collapse into human; json/mixed collapse into application.)
3. Model the result as data, not a constant-prefixed log line — emit driver_path/browser_path directly.
4. Failure is the exit code — the reason is logged to stderr (shown to a CLI user, replayed by a binding), never scraped into the result payload.
5. Application mode streams logs on stderr, leaving stdout as the clean result document — and those streamed logs should be structured (one JSON object per line, e.g. {"level","timestamp","message"}) so bindings can replay them without each writing a text parser.

Relevant context / related issues

• [🚀 Feature]: Leverage streaming output in the bindings #13989 — "Leverage streaming output in the bindings" (open): the consumer-side tracker. This issue is the producer/contract it depends on; [🚀 Feature]: Leverage streaming output in the bindings #13989 keeps its per-binding checklist (Ruby/Python/Java/JS pending) and should be updated to consume the new contract rather than today's mixed.

Have you considered any alternatives or workarounds?

Fix the current --output modes in place rather than adding a new flag. Rejected because --output json/mixed are a consumed contract — Java/Python/Ruby/JS/.NET parse their exact shape — so changing their behavior in place breaks every binding at once. A new flag lets --output keep working through a deprecation window while bindings migrate deliberately. (Selenium Manager is in beta, so flags may change without guarantee, but a deprecation notice on --output still makes the migration explicit rather than silent.)