fix(spaces): unify shared-space album sort options across web and mobile (#966)

[Deeds67]

Fixes #966.

The sort options for a shared space's album list differed per platform: web offered six, mobile four. Two of those differences turned out to be cosmetic — mobile's "Name" is web's "Title" (albumName), and mobile's "Recently updated" is web's "Date modified" (updatedAt). Both platforms now offer the same seven options, in the same order, with the same default.

The unified contract

#	Option	Field	Default dir
1	Title	albumName	Asc
2	Number of items	assetCount	Desc
3	Date modified	updatedAt	Desc
4	Date created	createdAt	Desc
5	Most recent photo	endDate	Desc
6	Oldest photo	startDate	Desc
7	Recently linked	linkedAt	Desc

Mobile gains Date created / Most recent photo / Oldest photo; web gains Recently linked. Both platforms now default to Recently linked, descending — the most useful opening order for a collaborative surface. Only users who never touched a space-album view setting see the change; anyone with a stored preference keeps it.

No server and no i18n change

GET /shared-spaces/{id}/albums already returned every field needed, and all seven label keys already existed in all ten maintained locales. This is a client-only change.

Web: a fork-only layer, upstream untouched

web/src/lib/utils/album-utils.ts and web/src/lib/stores/preferences.store.ts are byte-identical to upstream/main and stay that way. The seventh option lives in a new fork-only web/src/lib/utils/space-album-sort.ts that handles RecentlyLinked itself and delegates the other six to upstream's sortAlbums.

Adding RecentlyLinked to upstream's AlbumSortBy would have been less code but wrong on correctness: AlbumsControls.svelte iterates the same metadata array, so the option would also have appeared on the regular /albums page, where linkedAt does not exist and the sort would silently do nothing.

Delegating rather than reimplementing also means a future rebase that changes upstream's comparators changes both surfaces together, and the delegation tests notice if the semantics move.

Mobile: derived from the query that already runs

watchLinkedAlbums already LEFT JOINs the assets and GROUP BYs to compute assetCount, so the two photo-date aggregates come from that same statement — no extra round trip, and the stream stays reactive.

Photo dates are truncated to a UTC calendar day to match the server's MIN/MAX(("asset"."localDateTime" AT TIME ZONE 'UTC')::date). Without that, two albums whose newest photos share a UTC day would tie on web but be time-ordered on mobile — a visible ordering difference on the very sorts added for parity.

Two bugs found and fixed along the way

• A latent upstream inconsistency: on an unrecognised sortBy, upstream's sortAlbums falls back to DateModified while findSortOptionMetadata falls back to MostRecentPhoto — so the pill showed one option's name while applying another's order. sortSpaceAlbums resolves through the finder before delegating, so both halves land on RecentlyLinked.
• A startup-crash hazard: EnumCodec.decode used values.firstWhere(...) with no orElse, and nothing between it and SettingsRepository.ensureInitialized caught the throw — an unrecognised persisted value crashed the app at launch. Adding three new sort modes would have made that reachable on downgrade, so EnumCodec now falls back instead of throwing.

The four pre-existing Dart enum identifiers are deliberately not renamed (only relabelled) — EnumCodec persists value.name, so a rename would silently reset every user who had that option selected.

Testing

Web: 4372 passing. Mobile: 3039 passing. check:typescript, check:svelte (585 files), eslint --max-warnings 0, dart analyze --fatal-infos and the dart format gate all clean.

The design spec (docs/superpowers/specs/2026-08-10-space-album-sort-parity-design.md) defines 29 numbered behaviour scenarios with a scenario-to-test map; each has a named home in the suites. Photo-date fixtures are built so the two date sorts disagree at the same direction — a comparator wired to the wrong field fails rather than coincidentally passing — and the same fixture is used on both platforms, which is what makes "parity" a checked claim.

Edge cases covered: albums with no photos sort last in both directions (matching upstream's sortUnknownYearAlbums); assets with a null localDateTime count toward assetCount but yield no date range; bulk-linked albums sharing a linkedAt order deterministically; empty and single-album lists across all seven options and both directions.

Known divergences, deliberately not closed

• Title collation: web uses locale-aware localeCompare, mobile code-unit toLowerCase() — Dart has no built-in collator.
• Search scope: web matches album name or description, mobile name only.
• Photo-date corpus: web's dates are server-computed over all assets, mobile's over locally synced ones.
• Web's space album table headers remain static and non-clickable, unlike /albums.

The last two are filed as follow-ups.