Inconsistencies in ServiceWorkerClients get and matchAll implementations

I had a look at Chrome, Firefox and Safari implementation of ServiceWorkerClients get and matchAll implementations.
They are not really aligned for fetch event resultingClientId.

For ServiceWorkerClients.get called synchronously using resultingClientId from a navigation fetch event handler:

1. Chrome is waiting for the document to be parsed before resolving the get promise. This is shown in https://wpt.fyi/results/service-workers/service-worker/controlled-iframe-postMessage.https.html where the fetch response is waiting on get promise to resolve.
2. Firefox and Safari are resolving the promise right away (I believe Firefox exposes the client URL about:blank and Safari exposes the request URL)

For ServiceWorkerClients.matchAll called synchronously from a navigation fetch event handler

1. Chrome is not exposing the resultingClientId client
2. Firefox is exposing the resultingClientId client (url is about:blank)
3. Shipping Safari is exposing the resultingClientId client (url is the request URL), though WebKit ToT recently changed to match Chrome to fix some potential issues in case of push event processing.

@asutherland, @yoshisatoyanagisawa, thoughts?

Start with the linked WPT result for controlled-iframe-postMessage.https.html and compare the described ServiceWorkerClients.get and matchAll behavior across Chrome, Firefox, and Safari when called during a navigation fetch event using resultingClientId. Done requires an agreed cross-browser behavior and corresponding specification or test changes, but the issue does not identify files or a proposed resolution.