Does a PWA install persist the directory grant

[stueydubs]

Question

Does installing the app as a PWA persist the directory grant, and does a picker grant behave like a drag-drop grant?

Hands-on work that a decision waits on, in the same shape as the now-closed #23. Both questions were raised by #19 and neither can be answered headlessly, which is why this is a task and not research.

Why it matters. #19 measured that a handle survives reload, tab close and a full browser restart via IndexedDB, but that the permission does not survive a same-tab navigation, and that requestPermission() rejects without a user gesture. That makes 1.0 a re-authorise-every-visit tool. Chrome documents that installed PWAs persist file-system permissions with no prompt at all. If that holds, the difference is between a tool that asks every time and one that remembers, which is a materially different product.

Resolve:

• Install the app (any minimal page with a manifest and service worker will do) as a PWA in Chrome, grant a directory, then close it fully and reopen. Does the grant survive with no prompt? Record the Chrome version and OS.
• Whether that persistence survives a browser restart and a reboot, not just an app close.
• Whether it is per-directory or blanket, and what revoking it looks like from the user's side.
• Separately: What a hosted web app can actually do with local files #19's measurement obtained its handle by synthesising a drag-drop through the DevTools protocol, because the native picker cannot be automated. Confirm by hand that a handle from showDirectoryPicker() behaves identically for permission lifetime. If it does not, What a hosted web app can actually do with local files #19's permission findings need re-reading.
• Whether Edge behaves the same as Chrome, since both are Chromium and both are in scope.

Also worth confirming by hand while you are in there, because it is a data-loss hazard rather than a preference: #19 measured that createWritable() without keepExistingData truncates the target to zero bytes on close. Open a writable, hit an error, bail, and the user's file is gone. Confirm it, and record whether an aborted or never-closed writable leaves the original intact.

Record results as a comment here, with versions, and say plainly which combinations were not tested.