Blueprints: ship a site kit for a vertical, so a client site is configuration

Custom blueprints already work. BlueprintCatalog reads Blueprints:Path on every list and
apply, validates a file with the same validator POST /api/content-types uses, and marks it
BuiltIn=false with Source set to the filename. Nothing needs building for the mechanism.

What does not exist is a kit for an actual vertical, which is what turns "someone asks me for a
hospital site" into configuration.

A hospital.json declaring page, department, doctor, announcement, site-settings (singleton),
contact-submission and appointment-request (not deliverable), paired with a matching preset in
barakoPress naming the same fields. Two files, both data, reused per client.

Two constraints that shape how kits are written, both verified:

• A reference must point at a type declared in the same blueprint, so a kit carries its own page
  type rather than assuming blog was applied first.
• Applying a blueprint whose type name clashes with an existing one refuses the whole blueprint
  with 409. So a kit is applied to a fresh tenant, not layered onto an existing model.

Worth deciding: whether kits live here, or in a separate BaryoDev site-kits repository mounted at
Blueprints:Path. A separate repo keeps vertical opinions out of the core release, which is
probably right.

Start by reading BlueprintCatalog and the validation behavior shared with POST /api/content-types, then inspect how barakoPress presets are structured. Define hospital.json with the listed types and same-blueprint references, and create the matching preset using the same fields. Done means both data files apply successfully to a fresh tenant without name clashes.