Release opaque file grants with weak structured-clone ownership #370

Problem

WebScene currently keeps every native FileSystemHandle wrapper in a strong JavaScript Map, so wrappers cannot be collected during a realm's lifetime. Dropping or navigating away from the final wrapper also does not call AppScene's existing appscene_file_panel_cocoa_release_grant_v2 authority. structuredClone(handle) consequently loses the branded handle state instead of creating a distinct same-entry wrapper.

JavaScript has no standard FileSystemHandle.release() method. Lifetime must follow wrapper, clone-packet, realm, and navigation ownership.

Bounded scope

• Replace strong handle retention with weak V8 bindings and a shared native owner for each opaque grant.
• Preserve the owner through pending structured-clone packets and create a distinct branded wrapper on same-origin deserialization.
• Reject cross-origin deserialization without exposing the token.
• Queue one bounded native release request when the final wrapper/packet owner is gone, including realm retirement/navigation; never queue a second release for the same owner.
• Add the public C ABI, generic broker, exports, runtime wiring, and AppScene adapter compile gate for the already-shipped release API.
• Add Chrome/WPT semantics plus lifecycle, security, 10k broker, memory/FD, 100-cycle, ABI, C11, export, and native adapter gates.

Deliberate boundary

IndexedDB persistence is excluded. The File System Standard stores an origin plus a restorable locator. AppScene currently exposes only live process-local grant tokens, so persisting those bytes would create stale or cross-profile authority. The native durable export/restore authority is tracked separately in AppScene.

Oracle

Chrome 153.0.8010.50 confirms that release is absent; structuredClone() and IndexedDB retrieval produce distinct branded handles whose isSameEntry() succeeds. Current WPT coverage is fs/FileSystemBaseHandle-postMessage-* and fs/FileSystemBaseHandle-IndexedDB*.