Confirmed by the last run: a working file's download_url is
chatgpt.com/backend-api/estuary/content?cid&id&p&sig&ts&v — the same route
the browser uses. So /files/{id}/download is the minting endpoint, and a
gizmo file's 403 is a refusal to mint the signature. That is why no amount
of scoping helped; we were turned away at the only door that issues them.
Nothing else in the estuary namespace serves files: 404 across the board.
But section B tested file_000000001b3071f5…, one of the seven DELETED
files, because it took the first failure without checking its class. Those
results say nothing about the eleven recoverable ones.
- Pick the target by probing /files/{id} and taking one that answers 200,
skipping (and naming) the deleted ones.
- Add two experiments: estuary/content with a ts but no sig, since
validation asked only for id/p/ts and never sig; and a working file's
freshly minted URL with the refused id swapped in, which shows whether
the signature is bound to the file.
JesseMarkowitz
b1da1df986