AB#137417: Allow resource & resources fields during upload to use object IDs

[Joselgc1]

Description

Adds support for MongoDB record IDs in uploaded resource and resources fields.

During XLSX uploads:

• Valid canonical MongoDB IDs are verified against the resource configured on the field.
• Valid IDs are stored as ObjectId values, activating record links.
• Invalid, malformed, or wrong-resource IDs are removed.
• resources fields accept semicolon-separated IDs and retain valid entries when others are invalid.
• Record insertion is awaited so insertion failures are handled correctly.

Useful links

• https://dev.azure.com/WHOHQ/EMSSAFE/_workitems/edit/137417

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• Unit tests for uploaded resource ID normalization
• ESLint and TypeScript build

Commands run:

• npx eslint src/routes/upload/index.ts src/utils/form/normalizeUploadedResourceFields.ts src/utils/form/index.ts __tests__/unit-tests/utils/form/normalizeUploadedResourceFields.spec.ts --ext .ts --no-ignore
• npm run test -- __tests__/unit-tests/utils/form/normalizeUploadedResourceFields.spec.ts
• npm run build

Unit tests cover:

• Valid single-resource IDs
• Malformed IDs
• IDs belonging to a different resource
• Semicolon-separated multi-resource IDs with mixed valid and invalid values
• Multi-resource values with no valid linked records

Screenshots

N/A, backend-only change.

Checklist:

( * == Mandatory )

• * I have set myself as assignee of the pull request
• * My code follows the style guidelines of this project
• * Linting does not generate new warnings
• * I have performed a self-review of my own code
• * I have put the ticket for review, adding the oort-backend team to the list of reviewers
• * I have commented my code, particularly in hard-to-understand areas
• * I have put JSDoc comment in all required places
• * My changes generate no new warnings
• * I have included screenshots describing my changes if relevant
• * I have selected labels in the Pull Request, according to the changes with code brings
• I have made corresponding changes to the documentation ( if required )
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules