I looked into this more and found a breadcrumb here: https://commons.wikimedia.org/wiki/Commons:SPARQL_query_service#API_endpoint

That lead me to a year-old SO comment from @Zbyszko, but aside from being so old it's using the wmflabs.org URL, the method doesn't quite work. However, by looking at the request headers in the browser, I realized if you use Zbyszko's approach but send "cookie": "wcqsSession=<token>", this works. So here is a working example:

https://public.paws.wmcloud.org/User:Dominic/WCQS%20API%20access.ipynb

I realize my token is exposed publicly there, but since you can only use it for queries in the WCQS anyway, and it will expire in a bit, it seems fine.

Some other questions I would like to see still in documentation:

1. How to generate the wcqsSession token? Even if it's a different call to MWAPI, can I do it via API calls?
2. If you must be logged in via browser because the user needs to click the "allow" button, can a URL be generated that can open the authorization popup on Commons in one click, or must the user load WCQS and then allow it to redirect them to the permission screen?
3. What is the expected expiry period for the session token? I haven't seen it in a while in the browser, is it based on time since recent activity rather than a set amount?
4. Is the wcqsSession token destroyed if a user logs out of their Wikimedia account?
5. Since user is authenticated and can be tracked, are there rate limits or other controls? (Trying to determine if we built this into a public web app where many users could be querying WCQS concurrently form the same token, would they hit limits?)

Also relevant to this task: most of the code samples provided in WCQS for a query (the button next to "download", "link") will not work without authentication, so this code needs to be updated or clarified in accompanying text.

I still can't see it worthwhile to document the existing workflow. It's so convoluted that I suspect anyone that's willing to follow it would simply monitor the connections in their web browsers development inspector and recreate what they see without any explicit documentation required.

Instead in T306899 i've reworked the re-authentication flow to use a second cookie that will allow the documentation to be written in a sane manner. Technically the old method still exists, but it becomes the fallback to the fallback, instead of the first line of re-authentication.

Proposed documentation: P34534

I'm intending to update the wiki page after WCQS deployment and re-verifying the updates work as expected.

Documentation is published on https://commons.wikimedia.org/wiki/Commons:SPARQL_query_service/API_endpoint