Run AI request paths under the browsing user's access

Problem/Motivation

AI tools and deferred processors execute under the current user's permissions, but several request paths trusted client-supplied data and relied on route-level access rather than entity-level access. The current page path, element selections and view mode all ride in the DeepChat / refresh request body, and route access (for example the Edit Mode permission) is not a proxy for view or update access on a specific entity.

To keep the assistant from surfacing or changing anything the browsing user could not reach directly, the read and refresh paths should gate on that user's access rather than on the route alone.

Proposed resolution

• RouteEntityResolver and ElementSelectionResolver only surface an entity as prompt context when the current user may view it; otherwise the selection is dropped rather than leaking its label through the prompt.
• The refresh and deferred-processing routes require entity.update, and the controllers reject an invalid client-supplied view mode the same way navigation_plus validates an Edit Mode load (BadRequestHttpException) so the deferred render path behaves identically to a normal load.
• Normalise the service IDs to the ai_plus.* convention, keeping class-name aliases for back-compatibility.

API changes

• Routes ai_plus.refresh_components, ai_plus.deferred_processing and ai_plus.deferred_retry gain _entity_access: 'entity.update'.
• DeferredProcessingController and RefreshComponentsController gain a NavigationPlusUi dependency and validate the client-supplied view mode before rendering.
• RouteEntityResolver and ElementSelectionResolver gain a BlueprintAccessChecker dependency (from entity_blueprint) for the view check.
• Service IDs renamed to ai_plus.route_entity_resolver, ai_plus.element_selection_resolver, ai_plus.ui_command_queue and ai_plus.page_refresh_commands, each aliased from its class name; the explicit SettingsFormAlter service definition is dropped in favour of hook autodiscovery.