[CLI]: snapshot/eval fail with a recoverable "browser not open" state error — agent callers retry instead of recovering

### What's going on?

When no browser has been opened yet, `playwright-cli snapshot` exits 1 with a human-readable message that callers have to parse in order to recover:

```
$ playwright-cli snapshot
The browser 'default' is not open, please run open first

playwright-cli open [params]
$ echo $?
1
```

For an agent/automation caller this is a *recoverable state* (a prior `open` is required), not a failure. In a real session with 699 tool calls and 152 failures, this same signal was retried 11 times before the caller worked out that `open` had to run first — i.e. the interface is not self-describing to a non-human caller.

Related: it is invisible until runtime which commands need an open browser; `snapshot`, `eval` and `run-code` all fail the same way.

### Suggestion

Either:

1. Auto-open the default browser on first use for `snapshot` / `eval` / `run-code` (or accept an implicit open), or
2. Return a stable, machine-readable error (e.g. `error.type = "browser_not_open"`) in addition to the human text, so callers can branch instead of retry.

Happy to test a fix if that helps.

### Version

`@playwright/cli@0.1.14`

Start by reproducing the closed-browser behavior with playwright-cli snapshot, eval, and run-code. Read the CLI handling for these commands and determine how a recoverable browser-not-open state should be represented for automation callers. Done means callers can distinguish this state without parsing human-readable text, or the documented implicit-open behavior works consistently.

Written by the indexing model from the issue text.