[TTP2-21] Project deletion fails in project hierarchy with semantic work package IDs

[op-chomper]

🤖 This is an AI-generated prototype.

• To ask for a change, write a comment to @op-chomper on this PR.
• To ship the PR, first make it yours: run gh adopt 24761 (setup guide).

📋 Implementation plan: https://gist.github.com/op-chomper/20ff7e42f5680037e3737f56df3bb207

Ticket

hxxps://qa.openproject-edge.com/work_packages/TTP2-21

What are you trying to accomplish?

Deleting a project failed when a work package in the project or a subproject had a semantic identifier. The database cascade removed the work_packages rows, but the foreign key from work_package_semantic_aliases to work_packages restricted the delete. The result was a PG::ForeignKeyViolation, and the projects stayed in the database. This change makes that foreign key cascade, so the delete succeeds.

What approach did you choose and why?

A new migration replaces the foreign key with an on_delete: :cascade variant. The work_packages.project_id foreign key already cascades at the database level, which bypasses the ActiveRecord dependent: :delete_all on the association. A matching database cascade on the alias foreign key is the reliable fix. I did not edit the original create migration, because it has already run on development and staging databases.

Screenshots

No visual changes.

Merge checklist

• Added/updated tests
• Added/updated documentation in Lookbook (patterns, previews, etc)
• Tested major browsers (Chrome, Firefox, Edge, ...)