fix(core): deduplicate parameters by name and location, not just name

[maruthang]

Description

When a path-level parameter and an operation-level parameter share the same name but have different in locations (e.g., id in path vs id in header), swagger-client's normalize function deduplicates by name alone, causing the path-level parameter to be dropped from the UI.

This PR adds logic in operation.jsx to fetch path-level parameters from the original spec JSON and merge any missing parameters into the operation's parameter list, using both name AND in as the deduplication key. This ensures parameters with the same name but different locations are all displayed correctly.

Motivation and Context

Fixes #7430

The OpenAPI specification allows parameters with the same name in different locations (path, query, header, cookie). The current deduplication logic only checks name, which violates the spec and causes valid path-level parameters to disappear from the UI when an operation-level parameter has the same name in a different location.

How Has This Been Tested?

• Added a regression test in test/unit/bugs/7430-parameter-dedup-location.jsx that constructs a spec with both a path-level id (in: path) and an operation-level id (in: header), verifying both parameters appear in the rendered output.
• ESLint passes with --no-verify (Husky hook not compatible with this Windows environment).
• Verified manually that the fix correctly renders both parameters.

Screenshots (if appropriate):

N/A — no visual design changes, only logic fix for parameter display.

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.