fix(sidebar): sidebar selection not working for spaces and shares (#278)

* fix(sidebar): sidebar selection not working for spaces and shares

The selection for spaces and shares in the sidebar was not working,
since the application had the current space as the Personal space even
if you were not on it.

The solution was modifying this behavior: set currentSpace to null if
you are in one of the shares pages or in the spaces page. This clears
the personal space and then the selection activates.

* fix: change lifecycle hook to clear currentSpace

Clearing the current space on onUnmounted introduced the bug fixed in
12e7e30, which happened when opening a file editor and then closing
it, because currentSpace was set by the personal space but cleared by
onUnmounted right after it.

Changing onUnmounted to onBeforeUnmount correctly makes the currentSpace
to be cleared before it is set again by the personal space. This fix
makes the if statement introduced by 12e7e30 unnecessary and also fix
the current bug, which was caused by the same statement.

* chore: remove leftover comments

fix(favorites): resolve project spaces before falling back to mount p…

…oints

Favourites can live in any space. When one had no matching space loaded, the
list went straight to fetching mount points - which made sense when project
spaces were always loaded at bootstrap, so a missing space could only be a
share.

Project spaces are now loaded on demand, so a favourite in a project also looks
"missing". That both triggered the expensive mount point listing needlessly and
failed to resolve the favourite, since the project space it actually belongs to
was never fetched.

Project spaces are now resolved first, and mount points only if something is
still unaccounted for - which is often not the case at all. The mount point
load stays unawaited, as before, so the list renders immediately and the space
labels fill in when it arrives.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

fix(external): remove the alerts container once its last alert closes

#app-alerts-container is position:fixed, full-width, z-index:9999. Its
padding classes (oc-px-xl oc-pt-xxl) give it real height even with no
alert children, so once the last alert was dismissed it kept sitting on
top of the page, invisible but still intercepting clicks on whatever's
underneath - in this case the header buttons.

Both close paths (the × button and an alert's own action button) now
remove the container too once it has no children left.

Fix dependencies cycle warning and tests

feat: 4336 - implement sharing hierarchy conflict handling

Handles the two 409 hierarchy-conflict responses introduced by Reva's
feat/share-consistency: a forcible child_conflict (creating/updating a
share would replace existing shares on contained subfolders/files, user
confirms or cancels) and a non-forcible parent_conflict (the share is
redundant because access already exists through a parent folder, user
is informed and may remove the redundant direct share).

- graph/sharing/conflict.ts: parses the 409 payload (error_type,
  can_force, conflicting_shares, message) and exposes the Force retry
  header, plus typed errors for cancelled/blocked/pending confirmations
  and user-initiated share removal.
- useSharesStore: retries add/update/delete share requests with the
  Force header once the user confirms a forcible conflict.
- useSharingHierarchyConflictConfirm / useSharingHierarchyConflictInform:
  dispatch the confirm/inform modals, batching deferred confirmations
  for multi-recipient invites and offering an 'update-share' wording
  variant for role-change confirmations (vs. the default create wording).
- SharingHierarchyConflictModal + sharingHierarchyConflictDisplay:
  groups conflicting shares by sharee and resolves each one's
  permission label by matching permission_type against the configured
  share roles' actual allowedResourceActions (read/write/deny), since
  the API only reports id, resource_id, path, permission_type and
  sharee - no role id.
- InviteCollaboratorForm: still surfaces indirectly-shared users in
  search (their role can be increased with a direct share), and defers
  per-recipient conflicts into a single batched confirmation.
- ListItem: reverts the role dropdown to the existing role if the user
  cancels or the update is blocked, and offers to remove a redundant
  direct share on parent_conflict.
- FileShares: wires the confirm/inform composables into add/deny/
  delete share actions.

RoleDropdown gets a revertToExistingRole method and reacts to
existingShareRole changes so ListItem can roll back an optimistic role
change. SpaceMembers is intentionally left untouched - space member
removal doesn't go through this 409 contract.

Co-authored-by: Gerard Mc Ardle <gerard.mc.ardle@cern.ch>

signed archiver

Show a warning banner when the view mode is forced

Displays response.data.forced_viewmode_reason from the app provider
in a warning alert, informing the user why the file was opened in a
restricted mode.

Add pagination filter in the projects page

Pagination existed, but users were not able to change the value in this page

Widen spacesState mock type to match spaces store

The spaces Pinia store exposes spacesInitialized, mountPointsInitialized and spacesLoading, but the shared PiniaMockOptions.spacesState test type only declared spaces and currentSpace. Tests passing the loading flags (e.g. DriveRedirect.spec.ts) were rejected by vue-tsc with TS2353.

Update new project link