[Spec] Be clearer about authentication ceremony privacy in 4.1.4

Before this PR, the spec was vague about the timing attack and also didn't
specify at all that an implementation must return a NotAllowedError instead of
the normal PaymentRequest NotSupportedError in the case of
no-matching-credentials. Whilst we don't want to enforce that UAs show a dialog
here (they may decide, for example, that a delayed response instead is
sufficiently privacy preserving), this PR does try to make the actual concern
clearer and more normative, and add a normative requirement for the return
value.

Should also improve the situation called out in
#142

spec.bs

@@ -623,11 +623,17 @@ input {{SecurePaymentConfirmationRequest}} |data|, are:
         |id| from |data|["{{SecurePaymentConfirmationRequest/credentialIds}}"].
 
 1. If |data|["{{SecurePaymentConfirmationRequest/credentialIds}}"] is now empty,
-    return `false`. The user agent must take care to maintain
-    [[#sctn-privacy-probing-credential-ids|authentication ceremony privacy]],
-    e.g., by presenting an alternative UI to the user such that the website
-    cannot detect the difference between no-matching credentials and the user
-    declining to authenticate.
+    return `false`. The user agent must maintain
+    [[#sctn-privacy-probing-credential-ids|authentication ceremony privacy]]
+    and not leak this lack of matching credentials to the caller, by:
+
+    1. Not allowing the caller to perform a timing attack on this outcome versus
+        the user declining to authenticate on the
+        [[#sctn-transaction-confirmation-ux|transaction confirmation UX]], e.g.,
+        by presenting an alternative interstitial that the user must interact
+        with.
+    1. Rejecting the {{PaymentRequest/show|show()}} promise with a
+        "{{NotAllowedError}}" {{DOMException}}.
 
 1. Return `true`.