Say the folder dialogue is the portal, and what the Flatpak has not proved

distribution.md §4, outstanding.md's FR-PLAT-LIN-3 entry, the Flatpak
manifest's comment and the README all said a library was chosen by
typing a path and that nothing in the tree called the FileChooser
portal. Since 6683c14 every folder the desktop asks for is chosen
through rfd's xdg-portal backend, so those sentences were false.

What they now say instead is narrower than "it works in the sandbox":
no Flatpak has been built here, so whether the portal's path opens a
library, holds across a restart and takes a sidecar is unobserved, and
volumes() still cannot see a host card. The chooser also landed in ui/
rather than behind the dr-plat seam distribution.md had proposed, and
both documents say so. FR-PLAT-LIN-3 gets a status note to the same
effect.

docs/dev/requirements.md

@@ -1187,6 +1187,12 @@ protocol is unavailable, FR-DSP-8's stated fallback applies.
 portals and credential storage uses the Secret Service portal, both verified to satisfy FR-NC-2 and
 FR-CAT-1 within the sandbox.
 
+*Status (2026-09-26).* Not verified, because no Flatpak has been built. Since 0.17.0 every folder the
+desktop asks for is chosen through the FileChooser portal (FR-EXP-6), so the filesystem half has the
+code it needs; whether the path the portal returns opens, persists and takes a sidecar inside the
+sandbox is unobserved ([distribution.md §4](distribution.md)). Credentials reach the session's secret
+daemon through a talk hole rather than the Secret Service portal, for the reason the manifest gives.
+
 #### Windows
 
 Specified in [windows.md](windows.md); a stated channel under NFR-COMPAT-2, not a v1 one.