Remove Duplication of QA Data on Eval and Submit Screens[#6792]

[spetros-do]

Issue:

QA data associated with locations that have been in more than one monitoring plan are now appearing multiple times on the eval and submit screens.

The views that return QA data for the eval and submit screens include a mon_plan_id column, which results in multiple records being returned when a location is in the workspace associated with multiple monitoring plans.

Background:

This behavior is new after the implementation of the configuration management changes, which introduced functionality that loads all historical monitoring plans into the workspace.

Prior to these changes, only active monitoring plans were loaded into the workspace, so there would only ever be one row for each QA record returned by the views that return QA data for the eval and submit screens.

Changes needed:

Determine if the mon_plan_id column is needed as a column in the views that return QA data for the eval and submit screens
if not:
remove the mon_plan_id column and update the views that return QA data to return a unique list of QA records (wihtout mon_plan_id in the view)
if so:
update the logic used in the UI to display the QA data to only show a unique list of QA records (while maintaining the mon_plan_id for its other identified purpose(s))
Update the sorting for the data returned by the views that return QA data for the eval and submit screens

Test Summary - oris, location (unit,stack), system/component id, test type, test number, year/qtr, end date/time
QCE - oris, location (unit/stack), system/component id, event code, event date/time
TEE - oris, location (unit/stack), system/component id, year/qtr

Changes Made:

• Modified 3 workspace services: cert-event-review-and-submit.service.ts, tee-review-and-submit.service.ts, test-summary-review-and-submit.service.ts
• Used business key deduplication via stable identifiers (oris + location + system/component + test attributes)
• Tie-breaking via leverages monitor plan begin dates via database lookup instead of GUID comparison
• Applied caching: monPlanBeginMap minimizes database queries for plan begin dates

Testing:

• Verify backend deduplication eliminates duplicate business records
• Confirm tie-breaker uses reporting period dates not GUID comparison
• Validate sorting matches requirements specification
• Test mon_plan_id filtering preserved for access control
• Integration testing with facilities having multiple monitoring plans
• Performance validation with caching implementation

[sonarqubecloud]

Quality Gate passed

Issues
13 New issues
0 Accepted issues

Measures
0 Security Hotspots
45.6% Coverage on New Code
50.6% Duplication on New Code

See analysis details on SonarQube Cloud

[spetros-do]

This PR replaces #724.