JUnit non-multipart import creates duplicate Test Run evidence attachments (types 0 and 4)

When importing a JUnit XML report containing Test Run evidence through the non-multipart endpoint, Xray creates duplicate attachment records in the database (AO_8B1069_ATTACHMENT) and corresponding files on disk.
For a single evidence file included in the JUnit report, two attachments are created: one with type 0 and another with type 4.

Steps to Reproduce

1. Prepare a JUnit XML report containing one test case with a testrun_evidence property and a single Base64-encoded ZIP attachment.
2. Import the report using the non-multipart endpoint: POST /rest/raven/1.0/import/execution/junit
3. Confirm that the Test Execution and corresponding Test Run have been created or updated.
4. Inspect the attachment records in the database.
5. Inspect the corresponding attachment files on disk.

Actual Result

• Two attachment records are created for the same imported evidence, one with type 0 and another with type 4.

• Corresponding duplicate files are stored on disk.

• This behavior occurs even though the JUnit report contains only one evidence item.

Expected Result

Importing a single evidence file should not generate redundant attachment records or physical files.

The evidence should be stored and associated with the Test Run according to Xray's intended attachment storage model.

Impact

• Unnecessary database and filesystem storage consumption.

• Potentially significant storage growth when importing large numbers of automated test results containing evidence.

• Increased attachment management and maintenance overhead.