Sure, but that level of reproducibility isn’t generally appropriate for a publisher to enforce (just because the publisher tested against PyPI or their own private index server doesn’t mean all consumers of that app should do so).
The part that seems most reasonable to me is having a conventional way to publish “tested dependency combinations” for projects that care to do so. I agree extras aren’t ideal for that task, but lock files aren’t ideal for it either (as you mentioned in your footnote, so I don’t think we really disagree here).
I mainly mentioned the extras option because of this rejected alternative listing in the original post:
Putting the transitive lock into an extra ticks at least the second box in that list (since the main dependency set is still abstract), and arguably checks the third one as well (for tools that are aware of any conventions adopted in this space)
It’s unfortunate that a transitive lock extra would have to list direct URLs instead of pinned versions to allow hashes to be included in that approach, but adding hash=<hash-algorithm>:<expected-hash> specifiers (or something along those lines) to the environment marker syntax feels like it would be a smaller change than devising a way to distribute full lock files via package index servers.