Spec uses incorrect settings object when fetching a module worker

In Update the algorithm uses "job's client" as "settings object" passed to "Fetch a module script tree". This client is whatever context called "register" or "update", and could even be null if this is a regular "soft update" check. Fetch a module script tree then uses this settings object to find the module map in which to look up modules to fetch. Obviously when client is null that wouldn't work at all, but even when client isn't null we shouldn't reuse the module map of the client that installed the service worker, rather we should be using an module map that is owned by the service worker (similar to how regular workers have their own module map).

Other than for the module map this client is also used as the client for the requests for actual scripts, both in classic and module scripts. This effects things like the referrer of the request. Not sure what the correct thing to do there is, but the answer to that might influence to correct fix for the module map issue.

Start with the Update algorithm and its use of “Fetch a module script tree,” then trace how the settings object supplies the module map and script request context. Compare the service worker case with regular worker module loading and review the three existing comments. Done means the specification defines the correct settings object and resolves both module-map ownership and request-context behavior.