Trees: declare a parent field on any content type, instead of one Pages type per deployment

Pages takes its type and field names from host configuration, `Modules:Pages` (`BarakoCMS.Pages/PagesOptions.cs:15-30`), bound once for the whole deployment (`BarakoCMS.Pages/PagesModule.cs:24`). The cycle and depth guard is already general and lives in core (`barakoCMS/Core/Hooks/ParentReferenceHook.cs:38`), but the only way to declare a parent field is code: a module registering the hook for one type and field. Sibling slugs are covered by core slug uniqueness per type (#717).

### Why it is too specific

One tree per deployment fits one site. A docs site wants sections, a bakery's shop wants a category tree, and two tenants on one API may use different page types or field names, which D22 expects since sites differ only in configuration. None of them gets a guarded tree without writing code, and two tenants cannot have different page types at all.

### The general concept

A reference field is declared a parent on its field definition, with a maximum depth, as tenant data. Core runs `ParentReferenceHook` for every declared parent field. Pages reads which type and fields form its tree from tenant data, with `Modules:Pages` as the default, so each tenant chooses. Navigation and resolve work over whichever type the tenant names.

### Where it lives

Core: the parent declaration and hook registration. Pages module: reading its type per tenant.

### Compatibility

Released. `Modules:Pages` stays the default for a tenant that sets nothing, so existing deployments behave the same. The parent declaration is an optional field on the definition. Additive on the HTTP surface.

### Done when

- A `category` type with a declared parent field refuses a loop with no code registered for it, and a test showing that fails before the change.
- Two tenants on one deployment use different page types for navigation and resolve.
- A deployment with only `Modules:Pages` set behaves as today.

Relates #887 and #842.

Found in the architecture sweep of 15 September 2026.

Read BarakoCMS.Pages/PagesOptions.cs:15-30, BarakoCMS.Pages/PagesModule.cs:24, and barakoCMS/Core/Hooks/ParentReferenceHook.cs:38 first. Trace how parent hooks and page type configuration currently work, then verify the stated done conditions: guarded category loops, different tenant page types for navigation and resolve, and unchanged default Modules:Pages behavior.

Written by the indexing model from the issue text.