fix(web): align filter panel sections across every view (#802)

[Deeds67]

Fixes #802.

The report

The filter panel showed a different set of sections depending on which view you were in. Photos offered 10 sections; Map offered 9, missing Text entirely.

Root cause

Each surface hardcoded its own sections array, and they had drifted apart:

Surface	Before	After
Photos, Spaces	10 (all)	10 (all)
Map (map-filter-config.ts)	9 — no text	10
Album detail (album-filter-config.ts)	8 — no text, no albums	9 (albums intentionally excluded)
Album asset picker	8 — shared the album-detail list	10

ALL_FILTER_SECTIONS is now the single source of truth every surface derives from, so a section added in one place appears everywhere. Exclusions must be justified in filter-section-parity.spec.ts.

Deliberate exclusion: albums on album detail

The reporter noted some divergence may be intentional, and this is the one case. asset.repository.ts:369,374 guards both isInAlbum and isNotInAlbum with && !options.albumId — scoped to a single album, the former is a tautology and the latter an always-empty set, and the server drops them. Rendering the section would give two controls that do nothing.

The asset picker is the opposite case and gains both albums and text: it isn't album-scoped server-side (timelineAlbumId is stripped in timeline-manager/internal/request-options.ts), so "not in any album" works there and is the natural way to find un-filed photos to add.

Server change: map markers

Adding text to the Map panel client-side alone would have been worse than the bug. The map timeline hits TimeBucketDto, which already supports description/originalFileName/ocr — but map markers go through FilteredMapMarkerDto, which had none of them. The pins would have kept showing assets the timeline had already filtered out.

searchAssetBuilder already implements all three predicates (database.ts:862,869,874), so this is three DTO fields plus three lines of pass-through — no join or index work.

Drive-by: rating parity

Found while tracing. getFilteredMapMarkers passed rating but never ratingIsMinimum, so searchAssetBuilder fell to its = branch — map markers matched exact ratings while every other surface matched >=, despite the DTO documenting the field as "Minimum star rating". Fixed here at Pierre's request, with its own tests.

Tests

TDD throughout — every test was watched failing first, including a temporary revert of ALL_FILTER_SECTIONS to confirm the localStorage upgrade-path tests were meaningful.

• filter-section-parity.spec.ts (new) — the regression guard: canonical set, per-surface exclusions with documented reasons, consistent ordering, no invented sections.
• map-filter-options / album-filter-options — text forwarding across all five builders, with edge cases: trimming, undefined, empty string, whitespace-only, each field independently, space-scoped variants, and buildMapTimelineOptions(undefined, ...).
• filter-panel.spec.ts — the upgrade path, which decides whether existing users actually see the fix: a returning Map user with a pre-fix stored section set gets text revealed, without un-hiding sections they deliberately hid, and without re-introducing it once they hide it post-fix.
• map-page.spec.ts — end-to-end: setting a text filter reaches getFilteredMapMarkers with all three fields.
• gallery-map.dto.spec.ts — the three fields via describe.each: plain strings, regex/wildcard characters verbatim, empty string, absent, non-string rejection.
• shared-space.service.spec.ts — pass-through (global + space-scoped + absent) and both ratingIsMinimum cases.

Verification

Gate	Result
server unit	5114 passed, 9 skipped
web unit	3689 passed, 2 skipped, 8 todo
server tsc / eslint / prettier	clean
web tsc / prettier	clean
web eslint	0 errors (613 pre-existing tailwind warnings)

OpenAPI + SDK + Dart client regenerated; the diff is confined to the map-markers endpoint.

Not included

FilterSuggestionsRequestDto still has no text fields, so suggestion lists are computed over a wider set than the grid shows. That is pre-existing and already true on Photos, so it's consistent rather than a regression — worth a separate issue if we want suggestions to narrow by text.

Docs

map-filtering.md listed neither Albums nor Text, and its closing section claimed the map has no location filter — the map config has included location for some time.