[Website] Coordinate OPFS Playground ownership across browser tabs

[ashfame]

Problem

Playground has targeted same-origin protections for OPFS metadata, but it has no cross-tab ownership model for initial setup or for a running saved Playground.

When two tabs load the same setup while an autosave is being created, a later tab can see initialOpfsSyncPending: true but cannot determine whether the creating tab is still copying files or has disappeared. PR #4244 intentionally treats that record as unavailable and creates a separate Playground, which avoids offering an unbootable restore but does not coordinate the two live tabs.

Current gaps:

• opfsSiteStorage.create() is an unlocked check-then-create sequence. Simultaneous requests using the same preferred slug can race.
• The initial MEMFS-to-OPFS copy has no cross-tab owner or lease.
• Autosave and pruning coordinators are scoped to one Redux store, and therefore one browser document.
• The in-memory OPFS metadata write queue is scoped to one document.
• Tabs load OPFS metadata into their own Redux snapshots without live cross-tab reconciliation.
• A completed saved Playground can be opened by multiple tabs without a single-writer lock for its OPFS directory.

Metadata updates do use a per-site Web Lock, and creation refreshes its slug candidates from OPFS. Those safeguards prevent stale metadata replacement and reduce ordinary slug collisions, but they do not establish runtime ownership.

Scenarios to cover

1. Two tabs simultaneously load the root URL with the same setup fingerprint.
2. Two tabs simultaneously request the same explicit site-slug.
3. A second tab opens a site while its first OPFS copy is active.
4. Two tabs open and modify the same completed OPFS-backed Playground.
5. Autosave pruning runs in two tabs while either tab has an active site.

Possible direction

• Use an origin-wide Web Lock keyed by setup fingerprint while selecting or creating an autosave.
• Hold a site-slug lock while a runtime owns and writes an OPFS-backed Playground.
• Let a later tab probe the lock to distinguish an active owner from an abandoned pending record.
• Define product behavior for an already-open Playground: focus the owning tab, wait, clone it, open read-only, or explicitly take ownership.
• Add two-page Playwright coverage for allocation, initial copying, and concurrent writes.

Related: #4243 and PR #4244.