test: qualify guided monitor setup and verify deployed user guides #1271

Result

Demonstrate that the complete guided-monitor journey works against the real backend, preserves the existing editor/API contracts, and matches the deployed documentation. This closes the parent feature after the preceding changes include their own focused tests and docs.

Parent: #1266. Depends on #1267, #1268, #1269, #1270.

End-to-end scenarios

1. Fresh unit administrator: target/coverage/cadence → create/select destination using a controlled delivery sink → review probe estimate → create/start → first result → remaining sample → active baseline → baseline/host evidence. Use deterministic real-stack fixtures; any actual scanner tests use authorized controlled listeners only.
2. Operator: existing destination selection and job execution succeed; management/high-cost controls stay unavailable. Viewer and platform-admin cannot enter or call the unit setup paths. Two-unit custom profile/destination/job IDs receive the same outcomes as unknown IDs.
3. Full TCP, selected-port Nmap, optional UDP, DNS uncertainty, excluded/huge CIDR, over-budget and unavailable-budget inputs; the review matches the saved job configuration.
4. Preview/create/run failures and conflicts, destination saved but job canceled, duplicate clicks, delayed/out-of-order requests, scanner/profile availability changes, queue cancellation, fast completed scan, and refresh/restart without duplicate creation or scan dispatch.
5. Guided↔advanced round trip, existing saved-job editing, browser Back/discard behavior, keyboard/focus/error announcements, desktop and supported mobile widths, and no secret in transferred/browser/cache state.
6. Baseline samples, failed/incomplete/stalled learning, active baseline with zero positive ports, explicit approval protections, and resumable work preserve existing semantics.

Build on e2e/real-stack.spec.ts, role/isolation fixtures, and existing accessibility/mobile specs. Do not create tests that only mirror implementation or broaden unrelated tooling/frameworks.

Documentation and deployment

Confirm the preceding changes updated, as affected:

• docs/src/content/docs/getting-started/first-scan.md
• docs/src/content/docs/user-guide/jobs-baselines-incidents.md
• docs/src/content/docs/user-guide/scanning.md
• docs/src/content/docs/user-guide/notifications.md
• docs/src/content/docs/reference/api-compatibility.md
• README quick start and SECURITY.md when their documented behavior/boundary changes.

Clarify chosen coverage, preview limitations, budget handling, separate destination/job persistence, explicit scan starts, and automatic sample learning versus optional baseline approval. Build/link-check docs and inspect the visible desktop/mobile journey in the docs preview, then verify corresponding production pages after deployment. Documentation deployment verification is part of completion under AGENTS.md.

Final gates

• Changed Go files formatted with the repository's Go toolchain; go vet ./... and go test -race -timeout=25m ./... pass.
• npm run lint, npm run build, npm run test:coverage, and npm run test:e2e pass; aggregate/per-package/diff coverage and normal CI/security gates remain satisfied.
• npm --prefix docs ci and npm --prefix docs run build pass, and preview plus production guide review is recorded with deployment evidence.
• No migration, dependency, runtime-configuration, scanner-execution, or Compose/release-pipeline change was introduced unexpectedly; if scope changes, invoke the applicable AGENTS.md checks instead of silently skipping them.
• API route inventory, isolation matrix, any new exported scoped-store cases, live-update audience, and secret write-only boundaries are complete.
• Existing advanced editor/create clients and saved-job revision/rebaseline behavior pass regression coverage.
• Before a separately authorized publish/release, the existing immutable-candidate, archived-artifact, multiarch-image, scanner-sandbox and runtime smoke gates remain the release authority.

Record task-based usability observations (completion, navigation, mistakes, coverage/baseline comprehension) without inventing percentage improvements or requiring analytics. No new telemetry service or dependency is in scope.

Estimated incremental effort: 4–6 hours, in addition to focused tests/docs already included in each implementation task. Close the parent only when the complete journey and deployed guides meet its acceptance criteria.