retrieval: mark deals cleaned_up when SP returns 404 for piece status

[SgtPooki]

Problem

Retrieval checks keep probing deals whose pieces have been deleted by the SP, while the FWSS dataset is still live. The candidate selector at retrieval.service.ts:373-391 only filters on status=DEAL_CREATED, metadata.ipfs_pin.rootCID IS NOT NULL, and cleaned_up=false. Nothing detects "SP no longer has this piece".

cleaned_up=true is set only by dealbot-initiated cleanup (piece-cleanup.service.ts:409) or dataset-level termination (deal.service.ts:894; also addressed by #548). Per-piece SP-side removal with a still-live dataset has no path back to cleaned_up=true.

Impact

Telemetry from staging (calibration, last 50 min): 21 of 63 IPNI verifications timed out — all on retrieval, none on data-storage. Direct GET <serviceUrl>/pdp/piece/:pieceCid/status returns 404 for all 5 sample pieces across 5 SPs. These are stale candidates polluting retrieval failure metrics and consuming 30s of timeout budget per attempt.

Proposed fix

In RetrievalService.performAllRetrievals, pre-flight probe SP /pdp/piece/:pieceCid/status before running IPNI verify + block fetch. On 404, mark cleaned_up=true + skip. Saves the 30s timeout and removes the deal from future candidate pools.

Optional secondary path: detection-driven cleanup if the retrieval pipeline observes both IPNI timeout and block-fetch 404 for the same (pieceCid, spAddress).

Next step

Implement pre-flight probe + cleanup write in RetrievalService.

Refs

• feat(jobs): add dataset_cleanup_sweep global job #548 dataset_cleanup_sweep — orthogonal (dataset-level terminated)