Export SW primitives needed by FedCM and Payment Handler for JIT registration

[monica-ch]

FedCM (see w3c-fedid/FedCM#842) and Payment Handler both need to perform just-in-time (JIT) service worker registration/unregistration from their own spec algorithms. The current SW spec exposes only a handful of exported algorithms — Handle Fetch, Fire Functional Event, Match Service Worker Registration, Request Matches Cached Item, and Lookup Race Response. The register/update/unregister primitives are all internal, so external specs currently have no stable way to programmatically manage service worker registrations.

@yoshisatoyanagisawa flagged this on the FedCM PR (comment), and @Brandr0id proposed three additions (comment).

This issue tracks adding three exported primitives to the SW spec so external specifications can integrate cleanly.

Proposed exports

1. Export Soft Update

Add the export attribute to the existing Soft Update dfn, plus small clarifying Notes for external callers (fire-and-forget contract; job-equivalence collapses duplicate calls). No algorithm behavior change.

2. New exported Register a Service Worker

A thin wrapper around Create Job + Schedule Job with job type = register, taking (storage key, script URL, scope URL, worker type, update via cache mode). Fire-and-forget; passes null for both client and job promise, so the resulting job has no referrer. Includes a Note that the same-origin gate against the referrer is skipped, so callers must satisfy the same-origin precondition themselves.

3. New exported Unregister Service Workers

Bulk unregister by storage key: iterate the registration map for matching storage key entries, parse the serialized scope URL, and schedule an unregister job for each.

Rationale

Both FedCM and Payment Handler already do effectively this from their own specs, but by calling non-exported SW primitives directly. Providing exported wrappers:

• Keeps external spec text stable across future SW internal refactors
• Encapsulates the SW-internal job-scheduling model behind a stable interface
• Follows the same pattern as Fire Functional Event, which is already the exported entry point for functional event dispatch

Non-goals

• No changes to any internal algorithms
• No new capabilities exposed to JS-facing APIs
• No Payment Handler-specific coordination — Payment Handler can adopt independently
• Not a redesign of the job queue or registration lifecycle

Proposed PR split

• PR 1: Export Soft Update
• PR 2: Add Register a Service Worker
• PR 3: Add Unregister Service Workers

Related

• Add initial Identity Handler SW Registration Tie In. w3c-fedid/FedCM#842 — original motivation
• FedCM's follow-up PR (not yet filed) will use Fire Functional Event for event dispatch (already exported)
• Payment Handler (w3c/payment-handler) has the equivalent gap