docs: docs-tests harness for Console UI drift detection

[marcel-rbro]

Part of #2671

Adds docs-tests/ — a docs-as-tests harness that catches when the platform docs claim something the Console UI no longer does (a renamed tab, moved route, relabeled button).

Model: an adjustable list of docs pages → AI-extracted assertions (run locally, human-reviewed) → a committed baseline → evaluated against Console staging with Playwright. Failures point back to source_file:line.

Includes the scheduled GitHub Action (docs-ui-tests.yaml, weekly + manual dispatch) that runs the evaluation against staging and files a drift issue on failure. Extraction never runs in CI, so no API key is needed there; the staging target and login come from repo secrets at run time — nothing is committed.

Coverage starts with the Console section (routes + landing-page elements); widening is a follow-up. See docs-tests/README.md for the model and known gaps.

🤖 Generated with Claude Code

[apify-service-account]

✅ Preview for this PR (commit b2caab7c) is ready at https://pr-2669.preview.docs.apify.com (see action run).

[marcel-rbro]

How to test this PR

The evaluation harness is just branch files, so most testing needs no CI. Note the CI constraint up front: workflow_dispatch and schedule only fire from the default branch, so the workflow can't be launched from this PR branch via the Actions UI — use a local run or a push-trigger branch to exercise it pre-merge.

1. Local run — fastest, tests the harness + baseline directly

cd docs-tests
pnpm install
pnpm exec playwright install chromium
cp .env.example .env      # fill in CONSOLE_STAGING_URL + seeded-user email/password
pnpm test                 # evaluate the committed baseline against Console staging

• pnpm report — HTML report with screenshots/video/trace for any failure
• pnpm issues — machine-readable output/issues.json (one entry per failing assertion, with source_file:line)

Expected on this branch: 41 passed · 5 skipped · 0 failed. The 5 skipped are detail-page assertions with no landing route (a documented gap, not a failure).

2. See a failure / the drift report

Point one assertion at something that doesn't exist (edit an assertions/*.json target) and re-run pnpm test. It lands in output/issues.json with the offending source_quote, source_file:line, and the live page's observed candidates. In CI, that same failure files (or comments on) a docs-ui-drift issue.

3. Exercise the actual GitHub Action on a branch (pre-merge)

Because dispatch/schedule only fire from the default branch, use a branch that carries a push: trigger:

• Dedicated canary / CI-test branch — docs/ui-tests-ci-check. A throwaway branch that mirrors this PR's content plus two things deliberately kept off master: a temporary push: trigger scoped to the branch, and a canary assertion (docs-tests/assertions/_ci-canary.json) that always fails. Push any commit to it and the workflow runs on the real runner end to end — logs in via the CONSOLE_STAGING_* repo secrets, the canary fails on purpose, the Playwright report + issues.json upload as artifacts, and a docs-ui-drift issue is filed. This is the sandbox for exercising the full failure path (drift detection + auto-issue) without touching master or this PR branch. Delete it after merge.
• Temporary push trigger on your own branch. Same technique for testing other content: add a push: trigger scoped to your branch in docs-ui-tests.yaml, push, then remove it before merge.

Neither the push trigger nor the canary is part of this PR — they exist only on the test branch, so master keeps just workflow_dispatch + the weekly schedule.

4. After merge (production)

The workflow becomes available on master:

• On demand: Actions → Docs UI drift tests → Run workflow (workflow_dispatch)
• Automatically: weekly schedule (Mon 06:00 UTC)

On failure it uploads the report + issues.json and files/updates a docs-ui-drift issue for maintainers.