Release v4.125.0

Part of #457 (epic Cratis/Scene#96). Needs Cratis/Scene#150 (released as 4.53.1), which lets the approved package set accept a blueprint manifest as published.

Added

• The Stage ships PrimeReact and Cratis.Blueprint.Default in the catalog a ui profile is resolved against, next to core, scene.web and Cratis.Components. A domain blueprint (@cratis/scene.blueprint.crm, .ticketing, .approvals, .inventory, .hr, .project-tracker, .administration) now only needs approving itself. The declarations are generated from the real package manifests (shippedPackages.spec.ts fails when Rendering.Cratis/Shipped/ShippedPackages.json is stale), and core:* component names resolve.
• A live Stage and a generated React application load the screen and dialog templates of the approved blueprints, so template blueprint <Package> <Template> renders the blueprint's template. A live Stage maps @cratis/scene.blueprint.default, @cratis/scene.engine and @cratis/scene.model to its own instances, as it does for React.
• Verification/live-blueprints runs the Stage image against all seven published blueprints at 4.53.1 (approved set made from the published manifest as written) and asserts in a browser that every screen the blueprint's templates build mounts with content, with no load diagnostics and no sample data served. It is a new step of the live-custom-packages CI job.

Changed

• Bumped Cratis.Scene.Engine, Cratis.Scene.Model and the @cratis/scene.* packages to 4.53.1, which re-pins the digests of the generated frontend bytes.
• CratisRendering.ShippedPackages is composed from the generated manifests; ShippedPackageNames has five entries, so an approved package may not reuse PrimeReact or Cratis.Blueprint.Default.

Fixed

• cratis render of an application using a domain blueprint no longer fails with CLI-RENDER-009 (dependency on Cratis.Blueprint.Default / PrimeReact unsatisfied) or CLI-RENDER-002.