fix(spaces): offer a specific space album from every add-to-collection entry point (#965)

[Deeds67]

Closes #965.

The bug

Whether "add this photo to that Shared Space album" was possible depended on which screen you started from — and web and mobile disagreed about which screens worked.

Entry point	Personal album	Space pool	Album inside a space
Web — any surface	yes	yes	no
Mobile — main timeline / search / person	yes	yes	yes
Mobile — inside a personal album	yes	no	no
Mobile — favorites, archive, on-device album	yes	no	no
Mobile — asset viewer + → Album	yes	no	no

Two independent causes:

1. Web never listed space-linked albums at all. CollectionPickerModal loads personal albums plus writable spaces and stops. The only place it listed a space's linked albums was restrictToSpaceId mode, reached solely from a space surface with a non-owned selection ([bug] Contradictory notification when adding photo to album as non admin Editor ("Successful" but "File cannot be added") #764). So the target simply did not exist on any web surface.
2. Mobile has two pickers and only one knows about spaces. The fork's CollectionPicker was wired into general_bottom_sheet and space_bottom_sheet; every other add-to-collection surface still mounted upstream's bare AlbumSelector.

The fix

No server change. Permission.AlbumAssetCreate already has a checkSpaceLinkedAlbumAccess arm, so a space Owner/Editor holds add-permission on every album linked to that space. A space-linked album dispatches through POST /albums/:id/assets exactly like a personal one.

Web — a space row with albumCount > 0 becomes expandable and opens into an "Add to space" child plus one row per linked album, mirroring mobile's SpaceCollectionSection. Albums are fetched lazily on expand and cached for the life of the modal, so opening the picker still costs two requests however many spaces you're in, and one space is open at a time. Children join the same flat keyboard-navigable row sequence. A space with no linked albums clicks straight through to the pool, exactly as before, and restrictToSpaceId mode is untouched.

Mobile — CollectionPicker is now mounted on the album, favorites, archive and on-device-album sheets, and on the asset viewer's +. It gained source (the viewer dispatches as ActionSource.viewer), assets (the viewer has no multiselect, and falling back to the empty one would read as "nothing non-owned" and offer space targets for someone else's photo), and onCompleted (so the viewer keeps refreshing "Appears in" and popping its sheet now that the picker owns the dispatch). Each rewired surface also loses its bespoke addToAlbum copy.

Second commit: fixes from review

A multi-agent review of the first commit found a bug in the exact flow this issue is about, plus several smaller ones. All are fixed in af110f4, each with a regression test that was confirmed to go red against the unfixed code.

• Multi-selecting a space album silently added nothing. findByKey resolved keys against personal albums + spaces only — but a space album owned by another member has no album_user row for the caller, so getAllAlbums never returns it and it lives only in the expand-time cache. The row ticked, the footer counted it, then submit dropped it and called onClose(undefined), which both wrappers read as cancelled. Keys now resolve against the cache too.
• The keyboard caret was cleared on every expand/collapse, so a keyboard user could reveal a space's albums and then had no way to arrow into them. Now re-anchored on the space row — only when the caret was already in use, so a mouse click doesn't acquire a highlight.
• The pool child's multi-select state was computed and asserted but never rendered. It's now a component alongside the other row types, with its own checkbox, the shared scroll-into-view action, and an indent that lines up with the album children.
• Collapse-then-re-expand during an in-flight request fired a second identical one.
• The chevron was painted over by the hover checkbox.
• Mobile: ref.invalidate ran before the context.mounted guard; and the space-albums loading state was conflated with "this space has no albums", flashing that message on every expand — web already distinguished the two.
• Mobile test gaps closed: addToSpaceAlbum (the literal subject of this issue) had no coverage, and neither did the source pass-through on the album path — whose regression would make the asset viewer a silent no-op with a lying toast.

Correction: why the mobile partner sheet is still skipped

The first version of this PR claimed a partner's asset "can never reach any space target" and that "web hides the + entirely there". Both were wrong, and the code settles it:

• Permission.AssetShare is owner ∪ partner — access.ts:127-131 unions checkPartnerAccess. The space pool accepts a partner's assets.
• Web's partner route never consults getSelectionCapabilities; it renders <ActionButton action={Actions.AddToAlbum} /> unconditionally (partners/[userId]/…/+page.svelte:99).

The sheet is still skipped, but for the real reason: mobile's own selectionHasNonOwned rule treats any non-owned asset as unreachable, so the Spaces section there would always be collapsed behind a notice — and that notice is itself stricter than the server. Relaxing the rule needs mobile to know which owners are partners, which changes every surface the rule already governs. Out of scope here; recorded as follow-up.

One side effect worth flagging: viewing a partner's photo in the asset viewer now shows that notice where previously there was no Spaces section at all. Consistent with the timeline's existing behaviour, but it's the clearest surviving parity gap.

Other behaviour changes worth calling out

• Web: clicking a space row that has linked albums now expands it instead of adding to the pool. The pool is one click away ("Add to space"), and the row checkbox still means the pool.
• Mobile favorites: local-only assets are now uploaded and added instead of being skipped with a toast. (add_to_album_bottom_sheet_some_local_assets is now an orphaned i18n key; the branch was already dead, since a favorites selection is remote-only.)
• Mobile asset viewer: when nothing landed and the server reported failures, the sheet stays open instead of popping, so the user can retry.

Out of scope

• The issue's closing note about extending the Album filter to "filter by a specific album" is a separate feature request.
• Selections above MAX_SPACE_ASSETS_PER_REQUEST (50 000) still hide the whole spaces section, with the existing notice.
• Mobile has no add-to-collection on the space-album page, or on an album you can edit but don't own, where web does. Recorded in the design note with the other remaining divergences.
• Album sorting options in Shared Space are inconsistent between Web and Mobile #966 (album sort options differing between web and mobile inside a Space) is untouched.

Verification

Local: web 4363 unit tests, check:typescript / check:svelte (586 files) / eslint / prettier clean; mobile 3030 tests, dart analyze --fatal-infos lib test clean, dart format clean on every touched file.

Design notes: docs/superpowers/specs/2026-08-10-965-space-album-add-parity-design.md.