fix: make DFS block ordering assumption explicit

[BravoNatalie]

Part of #297

Description

processIpfsResponse in ipfs-retriever/lib/retrieval.js assumes CAR blocks are returned in DFS order by the SP's trustless gateway. This assumption is implicit, the code never validates the order= parameter in the SP's Content-Type response header. If an SP returns blocks in a different order, the request fails with "Unexpected block CID" on a valid CAR, with no clear indication of why.

All current SPs run Curio with frisbii, which is confirmed to return order=dfs. The assumption is safe today, but the failure mode if it's ever violated is silent and misleading.

Proposed solution

Parse the Content-Type header from the SP response and assert order=dfs. Return a structured error (e.g. 502 with a clear message) if the header is absent or has a different order= value, instead of letting the CID mismatch surface later.

Done criteria

• processIpfsResponse reads and validates order=dfs from the SP Content-Type response header
• Requests where the SP does not return order=dfs fail with a 502 and a descriptive log message,
  not "Unexpected block CID"
• Unit test covering both the valid order=dfs case and the failure case