Release v4.39.0

The Blueprint package kind (Part B 1.1, 3, 6): what a domain blueprint declares, the rules that say it is done, the version pin, the gallery catalog, the scaffold all seven domain blueprints start from, and the CI gate that holds every blueprint to it. The rules live in the engines and are shared by both (REN1/REN2); nothing is Studio-only.

Added

• Manifest (ScenePackage.blueprint, C# ScenePackage.Blueprint): BlueprintMetadata - domain, description, thumbnail, screenSet (named BlueprintScreens with template, parent, order and icon, i.e. the navigation) and defaultSampleData. Sample-data packs stay the existing sampleData references. TemplateMetadata.thumbnail for each template. There is deliberately no second version on the blueprint: the package version is the blueprint's version. The shared scene-model-shape.json keeps C# and TypeScript in step.
• verifyBlueprintPackage (C# BlueprintVerification.Verify), the definition of done: manifest kind and version; domain slug, description (at most 200 characters), thumbnail path and presence in the package; a non-empty screen set with unique names, titles, existing templates, parents in the set, no ancestor cycle and every screen provided; sample data present, references valid and in the package, a declared default when there are several; every template with display name, description, type from the vocabulary, a Business / <domain> category and a thumbnail, on top of the provenance describeTemplateCatalog already checks; every screen template placed by the slot resolver (unplaced, ambiguous and self-nested are reported); a dependency on the foundation set. A package with no blueprint block (a foundation blueprint) is held to the template, placement and sample-data rules only, or to all of them with requireBlueprintMetadata.
• Version pin semantics: evaluateBlueprintPin (C# BlueprintVersionPin.Evaluate) decides Current / UpdateAvailable / UpdateBlockedByPin / NotSatisfied / Invalid for a reference's pinned range against the installed and latest versions; defaultBlueprintPin is the caret range of the installed version. compareVersions / PackageVersionRange.CompareVersions are new in both engines.
• Gallery data: describeBlueprintCatalog (C# BlueprintCatalog.Describe) and the BlueprintCatalogFile shape (blueprintCatalog.json): per domain blueprint its description, thumbnail, version, license, dependencies, screen set in navigation order, templates with type, category and thumbnail, and sample-data packs with the default marked. Every domain blueprint ships its entry; the repository root blueprintCatalog.json collects them.
• blueprint-verification-fixtures.json, a shared corpus (27 verification cases, 5 catalog cases, 17 pin cases, 8 version comparisons) asserted by Engine.Specs/for_Blueprints (C#) and engine/for_blueprints (TypeScript), plus a specification that fails when a rule has no case.
• Scaffold: yarn new-blueprint <domain> ["Name"] ["Description"] writes Source/JavaScript/blueprint.<domain> (templates, screens, sampleData, thumbnails, manifest, bundle, provenance and the verifying specification). What it writes is already done.
• CI: yarn verify-blueprints fails when a blueprint package has no verifying specification, when its packed archive lacks thumbnails/, sampleData/ or the catalog or carries a thumbnail outside thumbnails/, and when the root catalog is stale. The build also scaffolds a package, builds, lints, tests and verifies it unchanged, so the generator cannot rot. The default and components blueprints verify themselves with the same function.
• Docs: blueprints/ship-your-own-blueprint.md - the domain blueprint layout, manifest, definition of done, version pins and catalog.

Changed

• Ambiguity is reported as a problem only for a domain blueprint: the foundation's generic nesting chain (ModuleWorkspace > FeatureSection > SliceSection) fits slots many templates declare and is chosen explicitly, so flagging it would be noise.

Part of #109