Honor granular permissions in Elsa Studio UI

## Problem

Elsa Studio does not currently appear to consistently adapt the UI to the permissions granted to the signed-in user. This makes restricted/read-only roles hard to configure and produces confusing UX when Studio renders actions that the user cannot actually perform.

A Discord report described a user trying to create an account that can only view workflow instances. They had to grant many endpoint-specific permissions, encountered permissions that are not documented in `authentication.md` such as `read:workflow-activation-strategies` and `read:log-persistence-strategies`, and saw authorization failures for feature endpoints such as `/elsa/api/features/installed/Elsa.RealTimeWorkflowUpdates`.

The same report also called out Studio behavior: delete buttons and other privileged actions are shown even when the user lacks the required permission, and failed API calls can surface as generic/unhandled errors instead of clear permission feedback.

Discord context: https://discord.com/channels/814605913783795763/1518881855728910377

## Desired behavior

- Studio should determine the current user's effective Elsa permissions.
- Pages, navigation items, buttons, menu items, and feature-specific affordances should only be enabled or visible when the signed-in user has the required permission.
- Where an action cannot be hidden ahead of time, authorization failures should result in a clear permission/unauthorized message instead of a generic unhandled error.
- Read-only use cases such as viewing workflow instances should have a coherent permission story.

## Backend/API dependency

This likely also needs backend support: Studio needs a reliable way to know which permissions apply to endpoints/features/actions. The API permission model should be consistent enough for Studio to reason about read-only access, including whether `read:*` style permissions are supported consistently across read endpoints.

## Acceptance criteria

- A restricted user can navigate Studio without seeing privileged actions they cannot invoke.
- Workflow instance read-only access can be configured with a documented, predictable permission set.
- Missing permissions for common Studio API calls are either documented or exposed through discoverable permission metadata.
- Unauthorized API responses are handled gracefully in Studio with clear user-facing feedback.

Start by reviewing authentication.md and the Studio pages, navigation items, actions, and feature endpoints described in the issue to map required permissions and current authorization failures. Trace how restricted users access workflow instances and how failed API calls are surfaced. Done means read-only users have a documented permission set, privileged affordances are filtered, and unauthorized responses produce clear feedback.

Written by the indexing model from the issue text.