Fix page tree to respect TAG and REGEX permission rules, improve specificity ranking

[lucaci32u4]

This patch addresses two issues in the permission system:

Page tree does not resolve TAG or REGEX rules

The tree resolver passes only path and locale to checkAccess(), so TAG and REGEX page rules have no effect on sidebar navigation. Pages that should be hidden or visible based on their tags appear incorrectly in the tree.

The resolver is adapted to fetch each page's tags from the pageTags table and includes them in the access verification. Folder nodes (no page id, no tag) are kept visible when at least one descendant page passes the full access check, so tag-gated or regex-gated subtrees remain navigable.

Rule specificity resolution is string length based

String length is an adequate measure of specificity for path-related checking, but REGEX and TAG page rules should use a different ranking algorithm.

Introduced a different ranking algorithm that keeps the original priority list with adequately counting path length indicator by counting the amount of segments and separators in the path fragment.

Tags, exact rules and regexes (to some extent) are applied surgically over the wiki tree, therefore they should have maximum specificity. Start and end matchers are the least specific, so they use segment counting.

1. EXACT - highest priority (MAX_SAFE_INTEGER).
2. TAG - MAX_SAFE_INTEGER - 1.
3. REGEX - MAX_SAFE_INTEGER - 2.
4. END - path-length based (segments + separators + 0.5).
5. START - lowest priority, path-length based (segments + separators). Example: Projects/test1 -> 3, Docs/Internal/ -> 4.

Deny still takes precedence over Allow.

Files changed

• server/graph/resolvers/page.js - tree resolver tag fetching and folder descendant check
• server/core/auth.js - new specificity-based rule ranking
• client/components/admin/admin-groups-edit-rules.vue - Admin UI help-text changes to reflect new page rule evaluation.

Testing

To test this feature, create a page inside a few folders (Docs/Projects/Test/page1) and give it the public tag.
In admin area, go to the Guest group and give it read:pages page rule for the public tag, and deny for the Docs/Projects/Test START path.

Without the changes here, the page1 would not be accessible by Guest because the deny rule overrides the allow rule by comparing path length to tag length.

With the changes here, the page is visible by guest as specificity now does not compare unrelated metrics. The public tag is applied surgically and is respected.

We are currently using the changes in this PR in our production instance. For example, the page here is made public using tags, while a Starts with rule denies access to all other projects in /Projects/.

Release and security concerns

Very complex page rules setups will need to be reworked before updating to the new Wikijs version as this patch changes the way how permissions stackups are evaluated.
Reliance on old page rule mechamism is not recommended (comparison between path length and tag length) but can happend in odd setups.

A note should be added to the release indicating that complex permission systems need to be reviewed before updating.

[Heroiu-Justinian]

This used to drive me crazy. Very needed addition.