Fix: Implement cascade delete for claims and claim reviews to ensure data integrity

[LuizFNJ]

Description

Summary of the changes

This PR implements a robust cascade soft delete functionality for the Personality and Claim hierarchy, migrating orchestration logic to a new ManagementModule to avoid circular dependencies.

Key Changes

• Cascade Delete Logic: Created ManagementController and ManagementService to handle cascade deletion for both Personalities (Personality -> Claims -> ClaimReviews) and Claims (Claim -> ClaimReviews).
• Performance & Efficiency:
  • Improved ClaimReview.listAll with aggregation and its own count.
  • Added a separate count for Home stats using countDocuments based on the query.
  • Refined Claim.listAll to include its own count for accurate totals, avoiding inconsistencies with previous global count.
• Code Robustness & Standardization:
  • Improved error handling, logging, and documentation in ClaimService and PersonalityService.
  • Refactored PersonalityService.getById and delete methods to fix E2E test failures and ensure accurate history logging.
  • Renamed misleading functions in ClaimReviewService and implemented findPublishedReviewsByClaimId for precise data retrieval.
  • Standardized a utility pattern for verifying MongoDB ObjectIds.
• Testing: Implemented comprehensive unit tests for ManagementService and ManagementController, covering success scenarios, NotFoundException, invalid ID formats, and unexpected errors.

Related Ticket #2265

👉 View Evidence on Notion

Type of change

• New feature (non-breaking change which adds functionality)
• Existing feature enhancement (non-breaking change which modifies existing functionality)

Testing

Relevant Testing Instructions

1. Unit Tests: Run npm run test to execute the new unit tests for ManagementService and ManagementController.
2. E2E Tests: Run npm run test:e2e to ensure the cascade delete functionality integrates correctly with the database and authentication guards.
   • Note: Ensure the database is initialized with test data to verify cascade behavior.
3. Manual Testing: Test the API endpoints for deleting a Personality and a Claim to verify that all associated sub-records are soft-deleted (isDeleted: true) and history records are created.

Scenarios Impacted

• Deletion of Personality records (now removes associated Claims and ClaimReviews).
• Deletion of Claim records (now removes associated ClaimReviews).
• Listing and counting of ClaimReviews and Claims:
  • Improved ClaimReview.listAll using its own aggregation and count logic for consistency.
  • Introduced a separate simple countDocuments count for use in Home stats.
  • Refined Claim.listAll with its own count to fix inconsistencies between listed items and total count.

Developer Checklist

General

• Code is appropriately commented, particularly in hard-to-understand areas
• Repository documentation has been updated (Readme.md) with additional steps required for a local environment setup.
• No console.log or related logging is added.
• No code is repeated/duplicated in violation of DRY. The exception to this is for new (MVP/Prototype) functionality where the abstraction layer may not be clear (comments should be added to explain the violation of DRY in these scenarios).
• Documented with TSDoc all library and controller new functions

Frontend Changes

• No new styling is added through CSS files (Unless it's a bugfix/hotfix)
• All types are added correctly

Backend Changes

• All endpoints are appropriately secured with Middleware authentication
• All new endpoints have a interface schema defined

Tests

• All existing unit and end to end tests pass across all services
• Unit and end to end tests have been added to ensure backend APIs behave as expected

Test IDs

• Include the test ID when adding new tasks or components.
• Check that test IDs are present in the modified components.

Merge Request Review Checklist

• An issue is linked to this PR and these changes meet the requirements outlined in the linked issue(s)
• High risk and core workflows have been tested and verified in a local environment.
• Enhancements or opportunities to improve performance, stability, security or code readability have been noted and documented in Project do Github issues if not being addressed.
• Any dependent changes have been merged and published in downstream modules
• Changes to multiple services can be deployed in parallel and independently. If not, changes should be broken out into separate merge requests and deployed in order.