Extract the content-type form renderer from the admin, while it still has one consumer

The admin already generates a form from a `ContentTypeDefinition`: it reads the fields, picks a control per type, applies validation rules and respects field sensitivity. The portal in BaryoDev/barakoBrew#4 needs exactly that renderer, and BaryoDev/barakoCMS#345's CLI needs the same understanding of what a valid definition looks like.

Extract it into a package while there is one consumer.

## Why now rather than with the portal

Extracting a component with one consumer is moving code. Extracting it with two, one of which is being written at the same time, is a refactor happening underneath new work, and the usual outcome is that the new surface gets its own copy "temporarily".

There is a second reason that matters more. Nothing currently proves the renderer is definition-driven rather than quietly coupled to admin routing, admin auth state, or the admin's own query hooks. The extraction is the test. If it comes out cleanly, the portal is mostly navigation and branding. If it does not, that is worth discovering in 4.0 rather than in the middle of 5.0, because the assumption that it comes out cleanly is what makes the portal look cheap.

## Scope

The renderer only. A form and a field, driven by a definition, with validation and sensitivity honoured.

Not the navigation, not the data fetching, not the auth. Those differ between a console and a portal and pulling them along is how a shared package becomes a framework nobody can change.

## Done when

- The admin renders its content forms from the package, with no behaviour change, asserted by the existing e2e pack staying green.
- The package renders a definition it has never seen, in a test that does not import anything from the admin app.
- Field sensitivity is honoured by the package rather than by the caller, so a second consumer cannot forget it.

Part of what 4.0 owes BaryoDev/barakoBrew#4. Related: BaryoDev/barakoCMS#345.