feat: apply page permissions to the Pages tab

[andresvillenas]

Applies Kentico's page permissions to the Pages tab, so editors only see the pages they can see in Xperience's own page tree.

Why

Channel and workspace filtering was already in place, but within a channel anyone with Access channel saw the status (path, type, dates) of every page, including sections their roles can't see in the page tree.

Changes

• Page permissions on the Pages tab. A page is listed only if the user's roles have Display on it through Kentico's page permissions (an access-control list set on the channel root and inherited until a page breaks inheritance). Administrators and roles with Manage permissions on the channel bypass them, as in Kentico (WebPageAclPermissions.DISPLAY, WebsiteChannelUIPermissions.MANAGE_PERMISSIONS).
• Pure rules in ContentSyncPageVisibility (unit tested):
  • a page on this instance follows its own list;
  • a page only on the target follows its nearest ancestor that exists here, or the channel root's list;
  • filtering happens before the listing counts, sorts and pages, so counts don't reveal hidden pages;
  • reorder tooltips never name a hidden page ("a page you can't see") or a hidden parent (ContentSyncReorder.HiddenMisplacedCount).
• Data gathering in IContentSyncScopeAccess.GetPageVisibilityAsync. Kentico's public IWebPageAclManager.GetPermissions costs about three queries per page and doesn't cache (decompiled, identical in 30.8.0 and 31.7.2), too slow for a large channel. So the page-to-list mapping is read in one batched query by object type name (cms.webpageaclmapping, whose Info class is internal, the same pattern as display names), and the public API is called once per distinct list. If the mapping query fails, the public API is called for every page (slower, never wrong); if permissions can't be read at all, the tab shows the generic error row, so a failure hides pages instead of showing them.
• Docs: admin page spec (Security and privacy, with the live results), Usage Guide (Give editors access), and the content tree indicators spec, which still referred to the abandoned custom ViewSyncStatus permission.

Testing

• 250 unit tests pass (new: visibility rules, pages only on the target, broken inheritance, unavailable target, and reorder tooltips that count hidden pages); format check clean.

• Verified live on 31.7.2 with the Playwright CLI, comparing the Pages tab with Kentico's own page tree for the same restricted user (sync-status-tester, role Article reviewer with Access channel):

  Role's permissions	Kentico's page tree	Pages tab
  Access channel + Manage permissions	every page	65 pages
  Access channel only, no page permissions	only the channel root	0 pages (before this change: 65)
  Display + Read on the root, inheritance broken on Articles without the role	everything except Articles	56 pages, all but the 9 under Articles

  The administrator saw 65 throughout. The permission changes were made in Kentico's admin and restored afterwards.