Follow-up to #767.

Why

#767 added Review again for failed reviews. It restarts through the normal POST /api/v1/scans. But markScanFailed cleared previous_version, so restarting a failed published-pair review compared against the default predecessor. That happened even when the original request, for example a /diff save, named a different baseline.

Clearing alone wasn't the whole problem. Most published-pair failures happen while fetching the packages, before the pipeline records any baseline. So the row usually had nothing to keep.

What changes

• A published pair's baseline is a request input, checked against the registry before the scan row exists. The start route now passes it to createScanJob, which writes it to previous_version for published rows only.
• The mid-run recordScanBaseline skips published rows. The baseline's package.json is reviewed bytes and must not replace a version the registry confirmed.
• markScanFailed keeps previous_version for published rows. Staged, auto-discovery and gate scans still clear it on failure, so for them a failed scan still names no baseline.
• reviewAgainRequest passes the kept baseline back as baselineVersion. The start route checks it exactly as it checks a first request: it must be a plain version that is published, or the restart gets a 404.
• Failed rows created before this change have no baseline, so their restarts still fall back to the default predecessor.
• No migration: previous_version is reused.

Verification

New tests:

• DB tests in test/workers/scan-baseline-record.test.ts:
  • a published pair is created with its baseline and keeps it through a failure;
  • the mid-run record does not overwrite it;
  • a gate scan is never created with one.
  • The existing test that staged failures clear the baseline still passes.
• Route test in test/workers/scans-published-pair.test.ts:
  • an explicit baseline, then a failure, leaves the baseline on the row;
  • restarting from that row queues the same pair;
  • a restart that names an unpublished baseline gets a 404.
• Client test in test/scan-review-again.test.ts: the restart request carries baselineVersion.

With the server change reverted, the four new DB and route tests fail. pnpm run verify:quick passes.

Limits

• Small visible change: a failed or pending published pair now shows its requested baseline wherever previous_version appears. That is the dashboard's "from X" and the package releases baseline label, which before showed nothing or "—".
• Unchanged: when a published pair completes, the final save still writes the baseline package.json's version rather than the registry-confirmed one. The two match on npm.

Docs

• docs/ui.md: the Review again paragraph says a published-pair restart names its requested baseline.
• docs/diff-baseline.md: covers the published-pair exception to writing previous_version before completion.