Restricted access - #756

Pure move of Item.get_abilities into the role backend so every
permission decision sits behind the same facade.

Each ability now reads as a named rule on ItemAbilities, fixing
the Sonar S3776 complexity of the former monolithic function.
Per-action properties also sketch the vocabulary a future ABAC
engine will implement, one check per action.

Sonar S3516 flags validate() because every return yields the
same attrs value. Merge the restricted early return into an
if/else with a single exit and move the ancestors validation
to a helper to keep cognitive complexity low; behavior is
unchanged.

The soft delete assertion sat inside the pytest.raises block and
never ran, hiding a wrong expected message. Indexer error tests
now keep a single raising invocation inside the block so the
failure source is unambiguous. Flagged by Sonar on PR #756.

TreeModel.parent() uses .last() which follows Meta.ordering
(created_at). After a move(), the grandparent created later
is returned instead of the direct parent. The parent path is
known statically, so look it up by equality instead of
scanning ancestors.

Allow folders to be marked as restricted. A DB constraint
prevents setting is_restricted on non-folder items.

A shortcut materializes the original location of a restricted
folder moved to the tree root. The OneToOne target enforces a
single shortcut per folder and a DB constraint ties the target
to the shortcut type.

Only an explicit owner can toggle restriction on a folder. A folder
needs a parent to host its shortcut on activation, while an already
restricted folder lives at the tree root and must stay deactivatable.

Restriction is structural: the folder physically leaves its parent
so inheritance stops applying without any query-level cut. A
shortcut materializes its origin location. Explicit link reach is
kept and defaults to restricted only when it was inherited.

The folder returns under its shortcut's current parent and the
shortcut disappears. Without a live shortcut the folder stays a
detached root. Inheritance applies again through the tree structure.

Explicit roles granted during restriction that are now covered by
inheritance are dropped, so the sharing screen does not keep dead
entries. Superior roles and roles without inherited counterpart stay.

The reach kept from the restriction period is reset to inherit when
the reattached parent already grants as much or more. A more open
explicit reach survives, matching the role normalization rule.

Owners activate and deactivate restriction on folders via PATCH,
gated by the restrict ability. The serializer keeps working on the
instance returned by the toggle since the item physically moves.

Shortcuts expose their target's id, title and a can_access flag so
the frontend can grey out entries pointing to folders the user
cannot open. The children listing prefetches the viewer accesses to
keep the query count flat, and the tree includes shortcut entries.

A restricted folder lives at the tree root but its members reach it
through the shortcut when they can open the containing folder. The
listing hides the root in that case so the folder shows up in a
single location, and keeps it for members without container access.

Deleting a shortcut removes the entry from the containing folder
without trashing anything. An owner excluded from the target acts
on the container only and can neither destroy, declassify nor read
it: the folder keeps its accesses, stays restricted, and surfaces
in its members' top-level listing.

Trashing a folder must not drag restricted folders with it: their
shortcuts are removed before the subtree is marked deleted, so each
target survives untouched for its members while the rest of the
branch goes to the trash as usual. Restoring the ancestor does not
bring the shortcuts back.

An explicit owner trashing a restricted folder leaves no entry
pointing into the trash. The folder restores as a detached root,
still restricted, reachable by its members from their listing.

Shortcuts are tree entries, not content: they never match a search,
never reach the search index, and leave no entry in an exported
archive. The target itself is indexed and exported through its own
root, so users excluded from a restricted folder cannot find its
content through search or an ancestor export.

Creating a child folder with is_restricted chains creation and
activation atomically, so the folder starts as a restricted root
with its shortcut in place. Only owners of the parent may use it:
a lower role would promote itself to owner through restriction.
Shortcuts themselves can never be created directly.