feat(scan): serve socket scan view from cached results with 202 polling (SURF-742)

[John-David Dalton (jdalton)]

What this does

socket scan view shows the results of a full scan. Today it asks the API to compute those results from scratch every time. This change makes it read a pre-computed (cached) copy instead, which is faster and cheaper.

It does that by adding ?cached=true to the request. The server has two possible answers:

• 200 OK — the cached results are ready. The body is the usual ndjson (one JSON object per line), and we parse and show it exactly like before.
• 202 Accepted — the cached results aren't ready yet. The server has kicked off a background job to build them and returns {"status":"processing"}. When this happens the CLI waits a moment and asks again, backing off a little each time (1s, then 2s, … up to 10s, giving up after 10 minutes). The user never sees the "processing" state — they just wait a bit longer and get the finished scan.

Which modes change: the default view and --json (the non-streaming modes that already buffer the whole response). The live --stream --json path is intentionally left untouched.

Why it's safe to ship on its own

This is self-contained. It uses the CLI's own HTTP helper (queryApiSafeTextWithStatus) and does not call the Socket SDK for this path, so it stays on the currently-pinned @socketsecurity/sdk (1.4.96) and needs no SDK release. CI is green on its own.

The separate effort to move socket-cli v1.x onto the latest SDK (4.x) is tracked as SURF-1446 — that is not required by, and does not block, this PR.

Implementation detail & parity with main

• New helper queryApiSafeTextWithStatus in utils/api.mts returns { status, text } so the caller can tell a 202 apart from a 200 (the existing queryApiSafeText swallowed the status). queryApiSafeText now delegates to it, so its behavior is unchanged for every other caller.
• fetchScan builds the ?cached=true request, runs the 202→200 backoff loop, and parses the 200 ndjson via an exported parseArtifactsNdjson.
• This mirrors how main's CLI already does cached scan reads (commits e5fb60b1 + f6741d2d), adapted to the older v1.x layout. It deliberately does not use the SDK's cached getFullScan, because that method returns scan metadata, not the artifact list scan view renders.
• --stream --json still calls the streaming full-scan method unchanged.

Verification

• tsgo, eslint, oxlint, biome: clean.
• vitest src/commands/scan/fetch-scan.test.mts: 5 tests via nock against the real HTTP path — 200 cache hit, 202→200 poll, 404 error, plus parseArtifactsNdjson valid/invalid line cases. No owned-module mocking.
• vitest src/utils/api.test.mts: 10 tests, no regression from the queryApiSafeText refactor.

Linear: SURF-742. Do not merge yet.

[John-David Dalton (jdalton)]

Withdrawing — the cached scan-view behavior (SURF-742) will land as part of bumping socket-cli v1.x to the latest @socketsecurity/sdk (4.x) under SURF-1446, rather than a bespoke direct-API poll. Superseding this branch.