feat: guide created jobs through first scan and baseline learning #1270

Result

After creation, users see whether their first scan was requested, queued, running, failed, or completed, and what is required for a usable baseline. This guidance is reconstructed from existing job/scan state after navigation, refresh, or daemon restart.

Parent: #1266. Depends on #1269.

Lifecycle integration

• Wire the guided review's Create and start first scan action to create once, navigate to the created job, and dispatch the existing runJob(id) once. Keep creation and run separate. A run rejection or network failure must preserve the created job and show a retry/check-state action, never call create again.
• Reuse the scan-request handling already in src/pages/JobDetail.tsx for queued/running/rapidly completed requests. Reconcile authoritative queued/active/history state after an ambiguous response; do not automatically re-run because a page refreshed.
• Add a focused next-action panel/component to job detail. Derive collecting/complete/updating/stalled baseline status via existing baseline presentation helpers and server state; do not create an onboarding-progress table or client success flag.
• Explain samples collected versus samples required and the next scheduled run. Offer 'Run another sample' only as an explicit, permitted action when there is no active/queued run. Respect paused schedules, unit budgets/capacity, cancellation, resumable cycles, and current profile/revision.
• Distinguish failed/canceled/timed-out/incomplete observations from successful baseline samples. Stalled learning links to the relevant scan evidence and target/profile correction. Never lower sample thresholds or automatically approve a baseline.
• Once a baseline is active, state that readiness applies to the configured coverage; offer baseline/host evidence and incident/activity links only under the user's existing permissions. An empty positive-port set is a valid complete baseline, not a setup failure.
• Preserve existing explicit 'use this scan as baseline', reset/rebaseline, acceptance, and suppression contracts; no new automatic engine decisions.

Acceptance and tests

• Create success + run failure leaves exactly the same created job open; retrying run does not create a second job.
• Duplicate click, accepted-but-not-started, queued, running, fast completion, ambiguous run response, cancellation, and resumable-work cases use the existing truthful lifecycle handling.
• Reload/navigation/back and a restart derive guidance from persisted records and do not silently issue another scan.
• One of two samples, next scheduled sample, no configured schedule, stalled learning, failed/incomplete samples, changed scope, active baseline, and zero positive ports are correctly described.
• Subsequent samples are explicit and role-gated; thresholds, history, isolation, budgets, and scanner/notifier sandbox policies are preserved.
• Query errors are distinct from 'no results'; live updates and fallback query refresh do not create duplicate requests or leak another unit's data.

Likely files: src/pages/JobDetail.tsx, new src/components/MonitorNextActions.tsx, src/baseline.ts, guided-creation integration, existing API/query/live-update paths, and focused action/behavior tests. Prefer reusing the existing handler rather than adding another scan execution API.

Update first-scan and jobs/baselines/incidents documentation to distinguish automatic sample learning from optional explicit approval and to cover stalled/no-positive-port states. Run frontend lint/build/coverage, targeted real-stack/browser cases, docs build and deployment review, and normal CI. Estimated effort: 4–8 hours.