[Feature] Locked Folder Searchable

[tbelway]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

The ability to search the locked folder once unlocked.
I imagine this would either behave similar to the archive search-ability, where it's an option for inclusion, but with the additional step of requesting the PIN if the folder is not currently unlocked.

Platform

• Server
• Web
• Mobile

[Miiyr]

POST /search/metadata, /search/smart, /search/random, /search/statistics and /search/large-assets already accept visibility: locked and gate it behind requireElevatedPermission(auth); without an elevated session the query falls back to not-locked. See server/src/services/search.service.ts.
So the PIN-gated behaviour asked for above is essentially available at the API level.

The locked folder view has no search entry point at all.

• On web, web/src/routes/(user)/locked/[[photos=photos]]/[[assetId=id]]/+page.svelte renders a plain Timeline with options = { visibility: AssetVisibility.Locked };.
• On mobile, mobile/lib/presentation/pages/locked_folder.page.dart is an app bar plus a timeline.

The search filter panel has no locked scope: SearchDisplaySection.svelte only exposes isFavorite and isArchive.
As a result none of the existing filters (context/text search, people, date range, country/state/city, camera make and model, media type, rating, tags) can be applied to locked assets from any client, even while the folder is unlocked. Past a few hundred assets the only way to find something is to scroll the grid.

Some notes here in case the feature is validated:

• A search entry point inside the locked folder view (web and mobile) that scopes every query to visibility: locked while the session is elevated.

• Reuse of the existing filter sections unchanged, just bound to that scope.

• Results dropped and the view left when the session re-locks (the web page already handles onSessionLocked).

Scoping the search to the folder itself, rather than adding an "include locked assets" toggle to the global search, keeps the default behaviour unchanged and avoids reopening the leaks fixed in #22879, #26185, #29639 and #30724.
Filtering by people additionally depends on faces of locked assets being reachable inside that scope only; #19810 tracks the current inconsistency there.