Clarify that request.origin cannot be "client" at certain points

Previously, the code implicitly guaranteed that a requests
origin could not be "client" after Step 10 of
https://fetch.spec.whatwg.org/#concept-fetch.

Other algorithms then simply relied on this fact. This is
confusing. Instead, we now explicitly assert that the origin
is not client whereever we need it.

Signed-off-by: Simon Wülker <[email protected]>

fetch.bs

@@ -2230,6 +2230,8 @@ or "<code>object</code>".
 return true:
 
 <ol>
+ <li> Assert: <var>request</var>'s <a for=request>origin</a> is not "<code>client</code>".
+
  <li><p>Let <var>lastURL</var> be null.
 
  <li>
@@ -2255,6 +2257,8 @@ return true:
 run these steps:
 
 <ol>
+ <li> Assert: <var>request</var>'s <a for=request>origin</a> is not "<code>client</code>".
+
  <li><p>If <var>request</var> has a <a for=request>redirect-tainted origin</a>, then return
  "<code>null</code>".
 
@@ -2350,6 +2354,8 @@ source of security bugs. Please seek security review for features that deal with
 <a for=/>request</a> <var>request</var>, run these steps:
 
 <ol>
+ <li> Assert: <var>request</var>'s <a for=request>origin</a> is not "<code>client</code>".
+
  <li><p>If <var>request</var>'s <a for=request>mode</a> is not "<code>no-cors</code>", then return
  true.</p>
 
@@ -3309,6 +3315,8 @@ request <a for=/>header</a> indicates where a
 given a <a for=/>request</a> <var>request</var>, run these steps:
 
 <ol>
+ <li> Assert: <var>request</var>'s <a for=request>origin</a> is not "<code>client</code>".
+
  <li><p>Let <var>serializedOrigin</var> be the result of <a>byte-serializing a request origin</a>
  with <var>request</var>.
 
@@ -6632,6 +6640,8 @@ agent's <a>CORS-preflight cache</a> for which there is a <a>cache entry match</a
 <var>response</var>, run these steps:
 
 <ol>
+ <li> Assert: <var>request</var>'s <a for=request>origin</a> is not "<code>client</code>".
+
  <li><p>If <var>request</var>'s <a for=request>timing allow failed flag</a> is set, then return
  failure.