Security: availability of endpoints according to islands

Being able to call an api endpoints when you have the main permission, even if the profile do not expose the island in the UX is not a security problem, just a restriction of functionality problem.
Because of complexity introduced and load we should only be concerned by 'view' and 'save'.

Access to view/edit to the parent entity concerned is enough to decide the view and save instance. (We have no delete the parent entity, that's good).
Save button permission check should be done on the related save function for each entities at the time of saving.

Save preset as well could be check and the save part.

Implemented in !407:

New IslandAccessCheck service gates the publishing endpoints (publish, restore, revert) to the state island, and save_as_preset to the menu_preset island plus the administer pattern preset permission.

Previously these routes only checked _entity_access: display_builder_instance.update, so users could hit the HTMX endpoints directly even when the corresponding island was disabled in the profile.

Added 6 kernel tests covering allowed, forbidden, missing profile, and missing permission.

PHPUnit green, PHPStan L8 clean, PHPCS clean. MR to follow.

Thanks @andres-alvarez, could you fix the style error detected in the ci please.

Follow-up coding standards fixes for IslandAccessCheck:

• new static → new self in the final class factory method.
• Added braces around the interpolated $island_id in the forbidden message string.

Both flagged by the CI pipeline. No functional change. MR to follow.

Thanks andres alvarez, I kept your commits and reworked the approach on top of them.

Instead of a _custom_access method per route, one access checker now answers a _display_builder_island: 'state' route requirement, so any island, contrib ones included, can guard its own routes the same way.

The permission check moved to MenuPreset::isAvailable(), so the menu item and the route follow the same rule, as decided in #4.

The profile and preset admin permissions are now declared by the main module, so the check also works without Display Builder UI.

I will take a look

Hi team!

Reviewed MR !407. The approach works for me: a _display_builder_island route requirement, with the permission rule kept in MenuPreset::isAvailable(). Two things to fix before RTBC:

1. Moving the permissions can delete roles on existing sites.

   On sites installed before this MR, a role granted administer pattern preset or administer display builder profile still stores

   dependencies.module:
     display_builder_ui

   in its config. After this MR those permissions come from display_builder. When display_builder_ui is uninstalled,
   Role::onDependencyRemoval() finds nothing to remove and returns FALSE, so ConfigManager deletes the role. This affects any role that holds these permissions but not view display builder instance

   Suggestion: add a post update that re-saves the affected roles, plus a test that keeps such a role through an uninstall of display_builder_ui

2. IslandAccessCheck passes NULL to addCacheableDependency() when the instance has no profile.

   testAccessWithoutProfile triggers: "Calling addCacheableDependency() with an object that doesn't implement CacheableDependencyInterface is deprecated in drupal:11.2.0 and is required in drupal:12.0.0" (#3232020). Suggestion: return early.

Addressed @smovs's review (comment from Oct 29):

1. Roles depending on display_builder_ui: added display_builder_post_update_recalculate_admin_permission_role_dependencies(). It re-saves the roles holding administer display builder profile or administer pattern preset, so core recalculates their dependencies and uninstalling display_builder_ui can no longer delete them. Covered by AdminPermissionRoleUpdateTest, with a control case for a role without those permissions.
2. NULL deprecation: IslandAccessCheck::access() now returns neutral() early when the instance has no profile, with the instance as cache dependency and cachePerPermissions(). addCacheableDependency() no longer receives NULL. testAccessWithoutProfile asserts it.
3. Documentation: docs/security-model.md already describes the _display_builder_island requirement, so no change was needed. I can add a sentence about the neutral result when there is no profile if you want it.