UI read-only

[solita-topip]

Summary

Fixes UI components to properly hide or disable interactive elements when a user has read-only access (disabled prop is set). Previously, some forms, buttons, and selectors were still visible or partially functional for read-only users.

Issue

1. Map: Hide action buttons and update cursor on map markers when editing is disabled

• Hidden map marker popup action buttons (create group, remove from group, connect to adjacent stop, etc.) when disabled is true in StopPlaceMarker.js
• Updated cursor style to auto and guarded onClick handlers when editing is disabled in QuayMarker.js
• Refactored duplicated !disabled && !belongsToNeighbourStop guard into a single canInteract variable in QuayMarker.js

2. Assistance: Disable select instead of filtering options for read-only users

• Replaced logic that filtered AssistanceAvailability options to only show NONE for read-only users
• Now uses the disabled prop on the Select component — all options remain visible but interaction is blocked

3. Alternative names: Hide new alternative name form when user has read-only access

• Conditionally renders NewAltName form only when !disabled in AltNamesDialog.js

4. Tags: Hide add-tag form and delete button when user has read-only access

• Hides the AddTagDialog component when disabled is true in TagsDialog.js
• Hides the delete IconButton in TagItem.js when disabled is true
• Passes disabled prop through TagsDialog → TagItem

EDIT: Translations are removed from this PR and moved into a separate one #1678
5. i18n: Correct Finnish translations for step-free access terminology

Unit tests

• Verified that read-only users cannot add/delete alternative names
• Verified that read-only users cannot add/delete tags
• Verified that assistance availability select is visible but non-interactive for read-only users
• Verified that map marker popup buttons are hidden for read-only users
• Verified cursor feedback on coordinate fields for read-only users
  - [x] Verified Finnish translations display correctly in the UI

Documentation

N/A

[solita-sabinaf]

One option could be to use disabled={disabled} in here, make canBeEdited be about isAssistanceServicePresent only, and then keep the looping logic under .map as it was before. But matter of personal taste, disabling this input for when user is logged in but isAssistanceServicePresent is false is fine too

[testower]

I don't have any strong opinion on this, maybe @a-limyr does? Otherwise, I'm happy with whatever you decide here.

[testower]

LGTM, but I would prefer a separate PR for the translations

[solita-topip]

Translations are now removed from this PR and a new one is created for them #1678