fix: recursively merge and deduplicate database_specific maps and arrays

[jeffrey-theog06]

Context / Problem

Addresses [Issue #1315]
(#1315)
(Point 2).

When merging reports (such as multiple AWS Inspector reports or updates), duplicate entries inside lists in nested database_specific fields (like cwes list of objects or nested lists in indicators) were being preserved, causing duplicated data in the final merged OSV JSON files.

Furthermore, if a nested object like database_specific.indicators existed in both reports, merging them would silently discard keys that already existed, rather than merging their contents recursively.

Solution

-> Refactored combineDatabaseSpecific in internal/report/merge.go to recursively traverse and merge maps, and append/deduplicate slices.
-> Added helper function deduplicateSlice utilizing reflect.DeepEqual to correctly and generically deduplicate arrays of any types (including complex structs/dictionaries like cwes).
-> Added helper function sanitizeAndDeduplicate to ensure initial reports are deduplicated.
-> Updated TestMerge_AffectedDatabaseSpecific to expect duplicate-free arrays.
-> Added new unit test cases covering recursive merges and nested object list deduplication (TestMerge_AffectedDatabaseSpecific_Recursive, TestMerge_AffectedDatabaseSpecific_DeduplicateObjects).

Verification

All unit tests in internal/report/ were successfully updated and extended to cover nested structure merging and deduplication.

[calebbrown]

Hi, I appreciate your interest in contributing.

However a decision about how to solve this problem has not been made.

Recursing through an arbitrary JSON object tree and collapsing duplicate entries without understanding the semantic context of those entries may have unintended consequences that need to be considered.

[jeffrey-theog06]

Thank you for the feedback Mr @calebbrown ! That is a very valid architectural concern.

The intent behind this PR was to address the specific issue of duplicate CWE objects and indicators (like domains/IPs) that get generated during ingestion/merging. Currently, the implementation only recurses within the database_specific map, but you are absolutely right that a completely generic recursive merge might have unintended consequences if other custom fields need to preserve duplicates.

If you prefer a more conservative approach, we can easily modify this PR to:

1. Restrict the deduplication strictly to known fields (like cwes and the lists under indicators).
2. Or, we can pause this PR and wait until the team decides on the preferred design/strategy for handling these fields.

Let me know how you'd like to proceed, and I'd be happy to adapt the code to match the preferred approach!