TE-27460: read the 404 a pdf poll gets before rendering finishes

[shrinishLT]

Follow-up to #558, which is merged. Found by running upload-pdf --sync end to end against stage for the first time, with the backend counterparts deployed.

Problem

Both documents failed instantly with a useless message:

[upload-pdf:error] Failed to fetch results for pdf1.pdf: [object Object]
{ "document_name": "pdf1.pdf", "snapshotStatus": "failed", "error": "[object Object]" }

A pdf's sync counter is only seeded once rendering has produced the page count, so the first polls legitimately hit the "key does not exist" branch of /snapshot/status, which returns a real HTTP 404. Axios throws on it, and httpClient.request rethrows a plain Error with no response, so the poller could not see the status and treated every throw as terminal.

The [object Object] came from the same place: request builds its message from error.response.data.error?.message || error.response.data.message || error.response.data, and that 404 body has neither message field, so an object was passed to new Error.

Web never reaches this state. ProcessSnapshot seeds the counter when the snapshot is accepted, so by the time the SDK polls, the key exists and the endpoint answers 202.

Change

getSnapshotStatus takes an opt-in that accepts 404 as a readable response rather than a thrown error. Only the pdf poller passes it. The web call site is unchanged and keeps the default axios behaviour.

Terminal errors are still terminal: anything that is not 200, 202 or 404 stops polling and reports the real error, as before.

Verification

Re-ran against stage with the fix. Both builds returned full results:

• baseline build, two documents, emitted in upload order, both success;
• comparison build, page 1 Changes found at 3.01% and page 2 Approved at 0%, each page resolving to its own baseline image.

🤖 Generated with Claude Code

https://claude.ai/code/session_01V4Hy9BKNiBTDThi87RYSqX