fix(scan): precise 403/404 access codes + already-running guard on POST /api/scan

[LanNguyenSi]

What

Two backend fixes to POST /api/scan + scanRepository.

Why

Surfaced by the reviewer of the depsight_rescan MCP tool. The route turned every access failure into a 500, and scanRepository created a new RUNNING scan on every call with no debounce, so a loop (web Rescan button or depsight_rescan) could spawn many concurrent synchronous scans and burn the user's GitHub API quota.

How

• Precise access codes: scanRepository throws a typed ScanAccessError(status): not-found 404, not-owned 403, owned-but-untracked 404. The POST handler maps it before the generic 500 fallback, so a genuine scan crash still returns 500.
• Already-running guard: before creating a RUNNING scan, short-circuit and return the in-flight scan (scanId, alreadyRunning:true) when one already exists for the repo within SCAN_RUNNING_WINDOW_MS (default 5 min, positive-finite override only). The success response surfaces status running vs completed.

Tests

• Scanner unit tests: 404/403/404 access cases, already-running guard (asserts scan.create NOT called and pins the guard query shape), and a negative control (fresh scan proceeds).
• Route tests: 404/403/500 mapping, 200 completed vs running, 401/400 guards.
• tsc, eslint, vitest (270) green. Route tests live in a separate file because vi.mock is file-scoped.

Notes / follow-up

• The guard is a debounce, not a hard mutex (findFirst-then-create is non-atomic; no DB unique constraint). Acceptable for the stated goal; a partial unique index would be needed for true concurrency safety.
• 403 for a not-owned repo reveals its existence to a non-owner, an intended task-requested tradeoff; repo IDs are non-enumerable cuids.
• Downstream callers reacting to the new alreadyRunning contract (export route 409 edge, depsight_rescan message) tracked in follow-up f62a0fbf.

Refs: agent-tasks 5e9a27bc