fix(validation): handle anyOf/oneOf schemas in required parameter validation

[maruthang]

Description

When a required path parameter uses an anyOf or oneOf composite schema without a direct type property, validateParam now derives the type from the first sub-schema. This ensures type-specific validation applies correctly and prevents JS errors when swagger-client's buildRequest receives incomplete parameters.

Changes:

• src/core/utils/index.js: In validateParam, added logic to check for anyOf/oneOf sub-schemas when paramDetails has no direct type, and set the type from the first sub-schema.
• test/unit/core/utils.js: Added 2 regression tests covering required parameters with anyOf and oneOf schemas (missing value, valid integer, valid string).

Motivation and Context

Fixes #5831

Required parameters with anyOf/oneOf schemas caused JS errors because validateParam couldn't determine the parameter type for validation. Without a type on the top-level schema, the validation logic fell through without applying type-specific checks, which led to errors downstream when swagger-client's buildRequest received incomplete parameter data.

How Has This Been Tested?

• Added 2 regression tests in test/unit/core/utils.js that verify anyOf and oneOf parameter validation for both missing and valid values.
• All 145 existing tests in utils.js continue to pass.
• ESLint passes with zero warnings on modified files.

Screenshots (if appropriate):

N/A - No UI changes.

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.