refactor: optimize history module architecture and fix pagination

[LuizFNJ]

Description

This PR delivers a major refactor of the History module to support Universal User Tracking (Internal, Chatbot, and M2M) and restores the Pagination system.

Technical Highlights

• Architecture: Transitioned from .find().populate() to a specialized Aggregation Pipeline to allow conditional lookups based on User type (ObjectId vs String/M2M) and to fix pagination metadata.
• Architectural Alignment: Refactored to a Thin Controller pattern by offloading business logic and parameter parsing from history.controller.ts to history.service.ts. The controller now acts strictly as an orchestrator, delegating the complexity of polymorphic user identification (Internal vs Chatbot vs M2M) to the service layer.
• Resilience: Refactored HistoryListItem and LocalizedDate with safety checks for null values and invalid dates, including the removal of hydration warnings by integrating properly with Next.js i18n.
• Performance: Applied the Static Extraction pattern and useMemo in list components to optimize long-list rendering and prevent unnecessary re-computations during pagination.
• API Integrity: Standardized historyApi.ts naming and improved error handling with optional typing (?) for safer, more predictable requests.
• Security: Added type-safe conditional checks in getDescriptionForHide to prevent runtime crashes when querying hidden or restricted content.
• Database Changes: Updated chatbot payload to be an object and implemented a frontend type guard for improved validation.
• Migrations: Added migrations to convert history internal user string entries to object IDs and update M2M users saved as strings into objects, preserving the old value as clientId.

Related Ticket #2188, #2069, #2070, #2196

Type of change

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

Testing

• Tested pagination by scrolling/clicking "Load More" with 10+ records.
• Verified that history entries created by M2M integrations display correctly.
• Verified that internal user profiles are still correctly populated via the new aggregation lookup.

Unit testing scenarios

• createHistory: verifies successful creation and error handling.
• getHistoryParams: validates correct param mapping and error on invalid ID.
• getDescriptionForHide: returns empty string if content missing/not hidden; returns description when hidden (mocked).
• getHistoryForTarget: returns paginated results correctly; handles empty aggregates.
• Mocks and spies are reset before each test (jest.restoreAllMocks() and jest.clearAllMocks()).

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.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
40.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[caneppelevitor]

@LuizFNJ Remember to move the tickets to needs migration