Render module screens from the API descriptor, so a module does not need code here

Counterpart to BaryoDev/barakoCMS#635. That issue adds a UI descriptor to the module contract; this one renders it. Neither half is useful alone.

## Where the console is today

Half generic, half hardcoded, and the split is not where you would want it.

`components/content/dynamic-form.tsx` renders any content type from its field definitions, so a module whose data is content types already has an editor and nobody wrote it.

`hooks/use-accounting.ts`, `hooks/use-feature-flags.ts` and `hooks/use-analytics.ts` are hand-written, one per module. #3 records four more modules with endpoints and no screen at all.

So every module in the API costs a pull request here, written by whoever owns this repository rather than by whoever owns the module. A third-party author cannot do it, and if they could, this repository becomes a directory of other people's screens.

## What to build

A renderer that reads the descriptor from `GET /api/modules` and draws:

- a list and an editor per declared document, reusing `dynamic-form.tsx` rather than a second renderer, since the descriptor names field types from `FieldTypeRegistry` on purpose;
- the declared actions, each calling its declared endpoint;
- navigation entries in the declared place.

And it hides what the caller cannot use, because the descriptor carries the capability for each screen and action. Note that hiding is not access control: the server still refuses, and this is about not offering a control that returns 403.

## The part that needs a decision here, not there

**What happens to the three hand-written module hooks.** Three options and they are not equal:

1. Leave them. The descriptor covers new and third-party modules; Accounting and Analytics keep their bespoke screens because a ledger and a chart are not a form. Cheapest, and it means two ways of doing the same thing forever.
2. Migrate what fits, keep what does not. Feature flags is probably a list and a toggle, which a descriptor expresses. A ledger is not. This is likely the honest answer.
3. Make the descriptor rich enough for all three. Turns a descriptor into a UI language, which is how this kind of thing becomes a product with its own roadmap.

I would take 2 and say so in the code, so the next reader knows a bespoke screen is a deliberate exception rather than something nobody got round to.

## Watch for

- **A descriptor is untrusted input.** It comes from an API that may be running a third-party module. Render it as data, never as markup, and never evaluate anything in it.
- **A module can be present and disabled.** `GET /api/modules` reports both, and #1 already records that `RUN_STATUSES` drifted from the server enum, so treat the descriptor's vocabulary as something to validate rather than to trust.
- **Version skew.** The console and the API release separately now. A descriptor field the console does not understand must be ignored rather than fatal.

## Done when

- A module declaring a document and an action appears in the console with no code in this repository.
- A screen the caller lacks the capability for is not offered.
- An unknown descriptor field is ignored rather than breaking the page.
- The remaining hand-written screens carry a comment saying why they are exceptions.