v6.1.1: CodeGen barrel fixes for fresh installs and retirement migration pre-cleaning

TL;DR

Correctness and installation fixes for the certified LTS line lts/6.1. This patch restores CodeGen’s ability to boot fresh databases by emitting default empty barrels, resolves legacy entity retirement migration failures during upgrades from v5.51.2, and hardens the core entity-deletion stored procedure.

MemberJunction 6.x is released under the Business Source License 1.1; 5.x and earlier stay ISC. What the licence grants, and what needs certification, is in the licence section of the v6 upgrade guide.

Bug Fixes

• Fresh installations are no longer blocked by unwritten CodeGen empty barrels (@memberjunction/codegen-lib, @memberjunction/installer): Since CodeGen transitioned to partition entities by their destination directories, the generators for entity-subclasses, GraphQL, and Angular were only called if they iterated over non-core entities. On a fresh database with no non-core entities, this partition was empty, which prevented the generators from ever running. CodeGen would report “complete” but leave packages/GeneratedEntities/src/generated/entity_subclasses.ts and the Angular generated-forms module unwritten, leaving both MJAPI and Explorer unable to boot. CodeGen now always includes the default directory with an empty group when configured to ensure the pre-change behavior of emitting an empty barrel is restored. Additionally, the installer’s post-CodeGen artifact check has been hardened to treat a missing entity_subclasses.ts file as a critical failure and explicitly names it, instead of blindly trusting CodeGen’s exit code.
• Database upgrades from v5.51.2 are no longer blocked by legacy entity retirement migration failures (@memberjunction/core): Upgrading active databases with existing Report data failed during the Phase-0 retirement migration because legacy entities (such as legacy Reports and Workflows) had inbound foreign key constraints that blocked their deletion. Specifically, spDeleteEntityWithCoreDependencies ran without a loud fail-fast option, causing cascading constraint violations to leave database metadata half-pruned, while the stored procedure itself deleted view categories before the views themselves. To resolve this, the retirement migration has been pre-cleaned to clear first-order dependencies (including Reports resource type dependents and saved-view run history) and use a bounded-retry loop over sys.foreign_keys to null nullable references and delete non-nullable child records. To protect customer data, the migration detects (without deleting) second-order dependencies (such as conversations or entity documents pointing to retired records) and halts with a descriptive error listing the blocking tables. Finally, spDeleteEntityWithCoreDependencies has been hardened with SET XACT_ABORT ON to ensure any blocked delete aborts immediately and loudly, handles nulling ResourceType.CategoryEntityID references, and deletes user views in the correct child-before-parent order.