fix: deduplicate retrieval candidates by service provider in ipfs-retriever

[BravoNatalie]

Part of #297

Description

When an ipfsRootCid maps to multiple Filecoin pieces (shards), as is the case for Storacha content, the query WHERE pieces.ipfs_root_cid = ? returns one row per shard. If all shards live on the same SP (the common case), selectRetrievalCandidate receives N identical candidates and retries the same SP N times on failure. This gives a false impression of redundancy and wastes the retry budget without increasing resilience.

Proposed solution

Avaliate SQL vs JS filter

Done criteria

• validateQueryResultsAndGetCandidates deduplicates candidates by serviceProviderId after the auth cascade
• Test: 1 ipfsRootCid → 2 shards on same SP yields 1 candidate
• Test: 1 ipfsRootCid → shards on two different SPs yields 2 candidates (one per SP)
• Existing store.test.js tests pass unchanged

Notes

• The sequential CAR block ordering assumption in retrieval.js is a separate deferred follow-up