startAuthentication({useBrowserAutofill: true}) can abort a newer modal ceremony started during its support check #829

Version: @simplewebauthn/browser 13.3.0 (same ordering in 14.0.0)

startAuthentication awaits browserSupportsWebAuthnAutofill() before it calls
WebAuthnAbortService.createNewAbortSignal(). If a second, modal
startAuthentication() is started while the first (autofill) call is still in that
await, the modal call arms its signal and calls navigator.credentials.get() first.
The autofill call then resumes, createNewAbortSignal() aborts the newer modal
ceremony, and the conditional request stays pending.

Result: the user's button click rejects with ERROR_CEREMONY_ABORTED; the older
conditional request wins.

Repro (pseudo):

1. const a = startAuthentication({optionsJSON, useBrowserAutofill: true})
2. before isConditionalMediationAvailable() resolves:
   const b = startAuthentication({optionsJSON})
3. b rejects with ERROR_CEREMONY_ABORTED, a stays pending.

In Chromium and WebKit isConditionalMediationAvailable() is an IPC round trip, so a
click task can land in the gap. In Firefox it resolves as a microtask.

Suggestion: make the newest call win, e.g. take a per-call token before the await
and reject the stale call with ERROR_CEREMONY_ABORTED instead of calling
createNewAbortSignal() when a newer call has started.