feat: support producing deterministic car streams

[SgtPooki]

The goal here was originally to support the full gamut of specs for IPFS gateways, but as Lidel points out below, we should probably stick to one since the car variants are SHOULD, until we get feedback from users that different is desired.

see https://specs.ipfs.tech/http-gateways/trustless-gateway/#car-order-request-query-parameter and https://specs.ipfs.tech/http-gateways/trustless-gateway/#car-order-content-type-parameter

[lidel]

additional caveats about signaling

• client

  • Ref. https://specs.ipfs.tech/http-gateways/trustless-gateway/#car-format-signaling-in-request
  • order alone is not enough, you need x explicit version and dups as well to have the same bytes in response
  • server may not support order and dups parameters and could return generic CAR with blocks in different or unknown order

• server

  • Ref. https://specs.ipfs.tech/http-gateways/trustless-gateway/#car-format-signaling-in-response
  • if deterministic order is supported, return explicit Content-Type

Note that those extra CAR features are SHOULD and not MUST. In practice gateway implementations may choose to only implement a subset of possible permutations of CAR parameters. for example, today in 2025Q1 we have two presets in the wild:

• boxo/gateway returns content-type: application/vnd.ipld.car; version=1; order=dfs; dups=n
• storacha returns content-type: application/vnd.ipld.car; version=1; order=unk; dups=y

@SgtPooki If the purpose of this issue is to figure out what CAR should be produced by verified-fetch, probably a good bet is to try to follow what is done in boxo/gateway (deterministic DFS responses without duplicates) and have the same bytes, unless we have a reason to do something different in JS.