[Spec] Restore changes since REC

As per the plan outlined in #1021#issuecomment-2107832273, we have now
created the CR Snapshot and published a new CR Draft
(https://www.w3.org/TR/payment-request/) that includes restoring
the address changes. The only remaining work for that plan is to restore
the previous changes that had been made since REC.

Changes included:
  - [Spec] Relax user activation requirement for show() #1009

Additional edits on tops of above changes:
  - Add note linking to issue #1022 for discussion of user activation
    relaxing conditions

Fixes #1025

index.html

@@ -1003,15 +1003,31 @@ <h2>
           <li data-tests=
           "payment-request-show-method.https.html, show-method-postmessage-manual.https.html">
           If the [=relevant global object=] of [=request=] does not have
-          [=transient activation=]:
+          [=transient activation=], the user agent MAY:
             <ol>
               <li>Return [=a promise rejected with=] with a {{"SecurityError"}}
               {{DOMException}}.
               </li>
             </ol>
+            <div class="note">
+              <p>
+                This allows the user agent to not require user activation, for
+                example to support redirect flows where a user activation may
+                not be present upon redirect. See
+                <a href="#user-activation-requirement"></a> for security
+                considerations.
+              </p>
+              <p>
+                See also
+                <a href="https://github.com/w3c/payment-request/issues/1022">
+                issue #1022</a> for discussion around providing more guidance
+                in the specification on when user agents should or should not
+                require a user activation for {{PaymentRequest/show()}}.
+              </p>
+            </div>
           </li>
-          <li data-tests="show-consume-activation.https.html">[=Consume user
-          activation=] of the [=relevant global object=].
+          <li data-tests="show-consume-activation.https.html">Otherwise,
+          [=consume user activation=] of the [=relevant global object=].
           </li>
           <li>Let |document| be |request|'s [=relevant global object=]'s
           [=associated `Document`=].
@@ -4492,6 +4508,32 @@ <h2 id="canmakepayment-protections">
           opening multiple windows (tabs or pop-ups).
         </p>
       </section>
+      <section>
+        <h2 id="user-activation-requirement">
+          User activation requirement
+        </h2>
+        <p>
+          If the user agent does not require user activation as part of the
+          {{PaymentRequest/show()}} method, some additional security mitigations
+          should be considered. Not requiring user activation increases the risk
+          of spam and click-jacking attacks, by allowing a Payment Request UI
+          to be initiated without the user interacting with the page immediately
+          beforehand.
+        </p>
+        <p>
+          In order to mitigate spam, the user agent may decide to enforce a user
+          activation requirement after some threshold, for example after the
+          user has already been shown a Payment Request UI without a user
+          activation on the current page. In order to mitigate click-jacking
+          attacks, the user agent may implement a time threshold in which clicks
+          are ignored immediately after a dialog is shown.
+        </p>
+        <p>
+          Another relevant mitigation exists in step 6 of
+          {{PaymentRequest/show()}}, where the document must be visible in order
+          to initiate the user interaction.
+        </p>
+      </section>
     </section>
     <section class="informative">
       <h2>