WIP: docs: refresh after iOS + web support (#50)

* docs: README covers iOS + web, surface both example apps

* docs(cli): document --ios-device and per-platform doctor

* docs: tighten README, fold examples into Docs list

* docs(runs): correct --clear-data lifecycle wording

Default behavior no longer wipes app data between runs; --clear-data is now opt-in.

* docs(getting-started): add iOS path, separate folio and folio-web

Document just test-ios under examples/folio, and distinguish the KMP
sample from the React + Vite folio-web sample.

* docs(inspect): document the eight panels

Lists Screenshot, ActionList, Timeline, ViolationsPanel, HierarchyPanel,
SnapshotTable, MetricsChart, ExceptionsPanel. Cross-links HierarchyPanel
to the spec language reference.

* docs(writing-specs): document setup export, flag noLogcatErrors as android-only

Mirrors pkg/spec/README.md so the manual covers the runner's setup-first
fall-through. Marks noLogcatErrors as Android-only so iOS/web spec
authors know it silently no-ops.

* docs(folio): document web target and iOS sanderling test recipe

After the KMP refactor folio also runs on wasmJs and the justfile exposes
just web, just web-build, and just test-ios. Surface all three.

* docs(folio-web): add README

Covers prerequisites, demo credentials, just test recipe, and how the
React + Vite host exposes state to the sanderling spec via stable ids
and data-* attributes.

* docs: scrub driver-implementation name from user docs

Drop the implementation tool name from README, cli.md doctor table, and
spec-language.md. These docs should describe behaviour, not the specific
underlying tool the native sidecar wraps.

* docs(development): scrub driver-implementation name from dev docs

architecture, design-principles, decisions now describe the native
sidecar by role (gRPC surface over OS UI-test pipeline) rather than by
the specific tool it wraps.

examples/folio-web/README.md

@@ -0,0 +1,59 @@
+# Folio (web)
+
+A React + Vite port of the folio personal-ledger app: login with demo
+credentials, create accounts, add credits and debits. Exists as the
+minimal web example sanderling runs its property-based specs against.
+
+## Stack
+
+- React 19 + Vite + TypeScript
+- Stable HTML `id` attributes on every interactive element so the spec
+  targets DOM nodes by id, not by aria-label parsing
+- `data-*` attributes (`data-cents`, `data-account-id`, `data-txn-count`)
+  carry structured numeric state for property assertions
+
+## Prerequisites
+
+- `just`
+- [`bun`](https://bun.sh) (installs the JS toolchain; the project uses
+  `bun.lock`, not `package-lock.json` or `pnpm-lock.yaml`)
+- Chrome installed (sanderling drives it via CDP)
+
+```sh
+bun install
+```
+
+## Demo credentials
+
+```
+email:    [email protected]
+password: ledger123
+```
+
+## Run a sanderling test
+
+```sh
+just test
+```
+
+The justfile boots the Vite dev server on port 5173, waits for the port
+to respond, then runs `sanderling test --platform web --bundle-id
+http://localhost:5173` against it. Override the port with `PORT=4000 just
+test`; `DURATION`, `SEED`, and `OUTPUT` work the same way as in the KMP
+folio example.
+
+Traces land in `./sanderling/runs/<timestamp>/`.
+
+## How it connects to sanderling
+
+- The spec at `sanderling/spec.ts` finds elements by HTML `id`
+  (`#email`, `#add-account`, `#ledger`, `#txn-amount`, ...). Anything
+  the spec touches has a stable id in the markup.
+- Numeric state the spec asserts on is exposed via `data-cents` and
+  similar attributes. The spec reads `el.attrs["data-cents"]` rather
+  than parsing currency strings out of `aria-label`.
+- Account cards expose `data-account-id` + `data-balance` so the
+  spec can correlate cards across steps without depending on DOM order.
+- `just test` invokes `sanderling test --platform web`, which connects
+  to Chrome via the Chrome DevTools Protocol; no extension or app SDK
+  is involved.