Pages: resolve returns block data ready to render, and block schema and presets are tenant data in the API

barakoBrew reads the block schema from the renderer: `src/hooks/use-block-schema.ts:39-45` in barakoBrew fetches `NEXT_PUBLIC_PRESS_URL/api/blocks`, one renderer address per console, whatever tenant is being edited. BaryoDev/barakoPress#33 plans to keep block presets and data bindings in barakoPress. The API stores a page's blocks in a `json` field and accepts any object or array (`barakoCMS/Core/Validation/FieldTypeRegistry.cs:77`). `GET /api/public/pages/resolve` (`BarakoCMS.Pages/Features/Resolve/Endpoint.cs:43`) returns the page and its breadcrumbs, and the renderer then fetches each block's data itself.

### Why it is too specific

It assumes one renderer that is also the source of truth for blocks. Plugins enabled per tenant (BaryoDev/barakoPress#25) mean two tenants on one console have different blocks, which one address cannot answer. A second renderer, a mobile app showing a school's pages, or the offline shell (#849) would reimplement presets, bindings and source queries. And a page saved with a misspelled block property is accepted and renders nothing.

### The general concept

A `blocks` field type in core, validated against a block schema stored per tenant. The renderer registers its schema with the API using its renderer key, so barakoBrew reads blocks from the API for the tenant it is editing. Presets and bindings are tenant data in the API. Page resolve materialises each block's sources and bindings in one response, so every client renders from the same answer.

### Where it lives

Core: the `blocks` field type and block schema documents. Pages module: resolve. Needs changes in barakoBrew and barakoPress, linked from the umbrella issue.

### Compatibility

The Pages module is released. A page type whose blocks are a `json` field keeps working, and moving it to `blocks` is opt-in. Resolve gains optional fields, which does not break the HTTP contract. barakoBrew keeps the renderer fetch as a fallback while a tenant has no registered schema.

### Done when

- Two tenants with different registered block schemas get different schemas from the API, with a test that fails before the change.
- A page write with an unknown block property on a `blocks` field is a 400 naming it.
- Resolve returns a block's bound entries in the same response.

Part of the decision on the API owning the site model, linked from the umbrella issue. Relates BaryoDev/barakoBrew#166 and BaryoDev/barakoBrew#159.

Found in the architecture sweep of 15 September 2026.

Start with barakoCMS/Core/Validation/FieldTypeRegistry.cs:77 and BarakoCMS.Pages/Features/Resolve/Endpoint.cs:43, then inspect barakoBrew's src/hooks/use-block-schema.ts:39-45 and the linked barakoPress work. Run the existing core, Pages, and integration tests before designing the tenant schema flow. Done means tenant-specific schemas validate block properties, invalid writes return named 400 errors, and resolve includes bound entries without breaking JSON-field compatibility.

Written by the indexing model from the issue text.