Clarify cache access in Handle Fetch

[yoshisatoyanagisawa]

The previous wording "the registration’s storage key’s name to cache map" was ambiguous. This change clarifies the mechanism for accessing caches during a fetch event handled by a service worker.

Specifically, it replaces the ambiguous phrase with a direct call to "obtain a local storage bottle map" from the Storage specification, using the reserved client's environment. This makes the process of retrieving the cache map explicit and aligns the specification with modern storage standards.

This addresses the issue raised in #1784

---

Preview | Diff

[yoshisatoyanagisawa]

@annevk Will you take a look?

[yoshisatoyanagisawa]

@sisidovski @domenic Upon #1784, I fixed the sentences on looking up the cache for the SW static routing API. It has been changed to use "obtain a local storage bottle map" in the storage specification, and uses reserved client as an environment.

[sisidovski]

How is this related to whatwg/storage#185?

[yoshisatoyanagisawa]

How is this related to whatwg/storage#185?

This PR is the scenario without the change.
My original intention was making the storage API to accept the storage key to look up the cache storage. However, in #1784 (comment), I was asked not to use the storage key if possible. (and I understand #1784 (comment) is suggesting to use reserved clients as an environment). If we go with that way, we do not need the way to look up the cache storage via storage key, and whatwg/storage#185 will be abandoned.

[domenic]

LGTM with nit

[yoshisatoyanagisawa]

@monica-ch Can I ask you to take a look?

[yoshisatoyanagisawa]

Thanks for the review, all.
@annevk Although I have merged the PR, I am happy to address comments if there is.