Ensure collection safety on /catalogs route

[jonhealy1]

Related Issue(s):

• None

Description:

This PR implements a "Safety-First" deletion policy for the Catalogs Extension. It fundamentally changes the behavior of DELETE operations to strictly separate Organization (Catalogs) from Content (Collections). Deleting a catalog now "disbands" the group but never destroys the underlying data, preventing accidental loss of large datasets.

Key Changes:

1. Safety Architecture ("Unlink & Adopt")

• Safe Catalog Deletion: DELETE /catalogs/{id} now removes the catalog container but strictly unlinks all child collections. If a collection becomes an orphan (no parents left), it is automatically adopted by the Root.
• Safe Collection Removal: DELETE /catalogs/{id}/collections/{id} now unlinks the collection from that specific catalog context only. It never deletes the collection data, even if it was the only parent.

2. Removed Destructive Features

• Removed cascade parameter: The ?cascade=true option has been removed. It is no longer possible to trigger a recursive data delete via the catalogs route. Intentional data deletion must now be done via the core /collections/{id} endpoint.

PR Checklist:

• Code is formatted and linted (run pre-commit run --all-files)
• Tests pass (run make test)
• Documentation has been updated to reflect changes, if applicable
• Changes are added to the changelog