e2e: replace browse/promote with a cli browser dev tool

The browse/promote pipeline (drive a flow, record it, codegen a test) was more
scope than intended. Developing and testing are two uses of the same in-repo
browser, not an auto-conversion between them.

Replace it with `cli browser <target>`: spin up a persistent, logged-in Chromium
pointed at the running instance (the same config the Browser test surface uses)
and drive it with goto / click / fill / type / press / eval / look, or attach any
CDP tool to the printed endpoint. A small detached daemon owns the browser
(Playwright's pipe-based launch, so no flaky connectOverCDP) and serves drive
commands over loopback. Developing with it and writing a scenario() are the same
primitive, with no recording or codegen.

Removes src/journey/ (steps/codegen/run) and the browse/promote CLI commands.

Author: RhysSullivan

e2e/AGENTS.md

@@ -130,37 +130,32 @@ When handing results to the user, follow the evidence contract in the root
 [AGENTS.md](../AGENTS.md) (direct run links + a live instance + what to try);
 [RUNNING.md](../RUNNING.md) has the current sharing/demo mechanics.
 
-## Authoring from a live browser (`browse` → `promote`)
+## Driving the app while developing (`cli browser`)
 
-You don't have to hand-write a browser scenario. Drive a running instance's web
-UI one step at a time, then turn the recorded journey into a committed scenario.
-The generated test drives the same Browser surface the exploration drove, so it
-is the real test, not a transcript of one — develop the flow, then crystallize
-it.
+The dev CLI can spin up a real browser pointed at a running instance and already
+signed in, so you can develop against the UI the way a test does. It is the SAME
+browser the `Browser` test surface uses (Chromium, dark mode, 1280x800, the
+identity's cookies), so developing with it and writing a `scenario()` are the
+same primitive: you drive it to figure the flow out, then write the scenario with
+those surfaces. There is no recording or codegen between the two.
 
 ```sh
 cd e2e
-bun run cli up cloud                            # a live instance to develop against
-bun run cli browse cloud goto /                 # each step REPLAYS the whole flow from a
-bun run cli browse cloud click link Policies    # clean browser and prints the page's controls
-bun run cli browse cloud at-url /policies       # (role · name) + a screenshot, so the next
-bun run cli browse cloud see "No policies yet"  # step is written against what's actually there
-bun run cli promote cloud "Policies · a fresh workspace has none"
+bun run cli up cloud                       # a live instance
+bun run cli browser cloud up               # logged-in browser, prints a CDP endpoint + page controls
+bun run cli browser cloud goto /policies   # drive it; each verb prints the page's controls + a screenshot
+bun run cli browser cloud click "Add policy"
+bun run cli browser cloud look             # re-read the page (url, title, controls)
+bun run cli browser cloud down             # stop it
 ```
 
-Each `browse` replays every step so far, so what you are building is, at every
-moment, exactly what `promote` emits — a step that doesn't reproduce fails here,
-not in CI. Steps: `goto <path>`, `click <role> <name>`, `click-text <text>`,
-`fill <field> <value>`, `press <key>`, and the assertions `see <text>` /
-`at-url <substring>`. `--label "…"` names a step (it becomes the `step(...)`
-group); `browse <target> show | undo | reset` manages the journey.
-
-`promote` writes `<target>/<slug>.gen.test.ts` and runs it against the live
-instance, producing the usual run artifacts (session.mp4, step screenshots,
-trace). A journey with no assertion is refused — a scenario must prove
-something. From then on the file is an ordinary scenario: edit it, add API/MCP
-checks, drop the `.gen` once it's yours. The journey itself lives in
-`.dev/<target>.journey.json` (gitignored), not the repo.
+Verbs: `goto <path>`, `click <text>` (matches a link/button by name, else any
+text), `fill <field> <value>`, `type <text>`, `press <key>`, `eval <js>`, `look`.
+`up --headed` shows a real window (for a human to watch); `up --no-org` signs in
+without an active org. The browser is a detached process that persists across
+calls; its state lives in `.dev/<target>.browser.json` (gitignored). Because it
+exposes CDP, you can also point any CDP-speaking tool (Playwright `connectOverCDP`,
+devtools, an agent's own browser automation) at the printed endpoint.
 
 ## Desktop targets (the app on real OSes, filmed)