Handle Fetch does a dubious SecureContext check on a reserved client

Handle fetch currently does this at step 12.1:

1. If reservedClient is not null and is an environment settings object, then:
  1. If reservedClient is not a secure context, return null.
2. Else:
  1. If request’s url is not a potentially trustworthy URL, return null.

It seems a bit dubious to check if a reserved client is a secure context. Until its execution ready a reserved client does not have a creation URL set. (Consider that a redirect could occur before execution ready, etc.)

The secure context check is not completely useless because it will still check if a reserved client iframe's parent is secure or not, but it won't take into account the actual request URL at all.

I think this check should probably be rewritten sa:

1. If request’s url is not a potentially trustworthy URL, return null.
2. If reservedClient is not null and is an environment settings object, then:
  1. If reservedClient is not a secure context, return null.

So, always check the request URL, but also ensure the reserved client is not already forced to be insecure.

Locate the Handle fetch algorithm and inspect step 12.1, especially the order of the reservedClient and request URL checks. Update the algorithm so the request URL is checked first while retaining the secure-context check for an environment-settings reserved client; done means the wording matches the proposed ordering.