Anonymous access checks of the Views analyzer ignore that an attachment display is only shown with the display it is attached to

Problem/Motivation

The anonymous access checks of the Views analyzer (modules/audit_views/src/Plugin/AuditAnalyzer/ViewsAnalyzer.php) judge every display only by its own access plugin: analyzeDisplayAccess() reads the display's access option, detectAnonAdminAccess() reports anon_accessible && is_admin as ANON_ACCESS_ADMIN, and detectUnrestrictedAccess() reports access "None" on non-admin displays as ANON_ACCESS_UNRESTRICTED.

That is right for pages, feeds, blocks, embed displays, entity_reference displays and EVA displays: Views checks their own access plugin when they are rendered or used, and that check is what protects their content.

An attachment display has its own access plugin too, and Views checks it (Attachment::attachTo() returns early when $this->access() is FALSE), so an attachment can be more restrictive than its host. But attachTo() only runs when one of the displays it is attached to (its "displays" option) is rendered, and those displays check their own access first. Anonymous users can therefore only see an attachment when both the attachment AND at least one of its host displays allow it.

The analyzer ignores the host, which produces false positives: an attachment with access "None" attached to an admin page restricted by permission or role cannot be seen by anonymous users, but it is reported as an ANON_ACCESS_ADMIN error (or as ANON_ACCESS_UNRESTRICTED on a frontend view). The only way to silence it is to duplicate the host's access configuration on the attachment.

Steps to reproduce

1. Create a view with a page display at admin/foo restricted to the administrator role.
2. Add an attachment display attached to that page, with access "None".
3. Make sure the view is considered an admin view (for example name it admin_foo).
4. Run drush audit:run views --format=json.
5. The attachment is reported as ANON_ACCESS_ADMIN although anonymous users cannot see the page it is attached to.

Proposed resolution

When an attachment is accessible by anonymous users through its own access plugin, also check its host displays (the displays listed in its "displays" option, with the default display options merged in, using the same analyzeDisplayAccess() logic). If none of them is accessible by anonymous users, mark the attachment as not accessible and add "(attached to restricted displays)" to its access label, so the report still shows the configured access. detectAnonAdminAccess(), the anonymous access statistics, the score and the access badge all read anon_accessible, and detectUnrestrictedAccess() also skips displays that are not anonymous-accessible.

If the attachment's own access is stricter than its host, it keeps being reported as not accessible, as today. If the host displays cannot be found, the attachment is judged by its own access only, as today.

Remaining tasks

- Add the host check for attachments in analyzeOneDisplay() (it now receives all displays of the view) and the anon_accessible condition in detectUnrestrictedAccess().
- Unit test with a data provider running analyzeDisplays(): restricted host + attachment "None" => no ANON_ACCESS_* item on admin and frontend views; open host + attachment "None" => ANON_ACCESS_ADMIN on an admin view and ANON_ACCESS_UNRESTRICTED on a frontend view; open host + restricted attachment => no item.

User interface changes

Attachments whose host displays are restricted show their configured access followed by "(attached to restricted displays)" and no longer produce ANON_ACCESS_* items in the Views audit report.

API changes

None.

Data model changes

None.