upstream: pull-source shape that targets a gateway directly

[SgtPooki]

Problem: The browser flow needs the shared redirect relay only because the provider's pull validation requires the source URL path to end with /piece/{pieceCid} (pdp/pull_types.go ValidatePullSourceURL), while a trustless gateway serves the same bytes at /ipfs/{cid}?format=car…. The relay contributes nothing but a 302 — the provider already validates pulled bytes against the on-chain commitment — yet it sits in every browser migration's path and its allowlist becomes a trust knob to operate.

Next steps:

• Raise upstream with Curio: either accept an arbitrary HTTPS source URL and rely on the commitment check it already performs, or accept a structured source descriptor (gateway URL + CID) it can rebuild the CAR URL from.
• Track the upstream issue/PR here once filed.
• Keep the relay (and its single-host allowlist) until a released Curio supports this.

Done when: a released Curio accepts a gateway-direct pull source, and the app and docs drop the relay from the passthrough path.

[SgtPooki]

Closing: both halves of the done-when hold.

curio#1358 merged 2026-07-16 and shipped in Curio v1.28.3 (2026-08-07): pull sources only need HTTPS, and the provider validates pulled bytes against the on-chain commitment. That is the arbitrary-HTTPS option from the next steps above. The web app dropped the relay from the browser flow on 2026-07-23; providers pull gateway CAR URLs directly.

The relay stays deployed for two CLI-only roles outside this issue's scope: the legacy pdp-submit --source-relay path and the streaming rebuild for assembled multi-asset CARs and truncating gateways (#45, #52). What this issue tracked was the 302-only passthrough and its allowlist trust knob, and that is gone.