fix(spec): wrap parameterMacro to handle undefined return values

[maruthang]

Description

Created a wrapParameterMacro utility function that wraps the user-provided parameterMacro callback. When the macro returns undefined, the wrapper substitutes the parameter's existing default value, preventing undefined from being used as a WeakMap key in swagger-client.

Applied the wrapper in all 3 places where parameterMacro is passed to swagger-client:

• resolveSpec in src/core/plugins/spec/actions.js
• debResolveSubtrees in src/core/plugins/spec/actions.js
• requestResolvedSubtree in src/core/plugins/swagger-client/index.js

Motivation and Context

Fixes #10448

When parameterMacro conditionally returns values (i.e., returns undefined for some parameters), swagger-client attempts to use undefined as a WeakMap key, which throws: TypeError: Invalid value used as weak map key. This makes it impossible to use parameterMacro to selectively override only certain parameters.

How Has This Been Tested?

• Added 8 unit tests in test/unit/core/utils/wrap-parameter-macro.js covering:
  • Returning the original value when macro returns undefined
  • Passing through falsy values like 0, "", null, and false
  • Forwarding both operation and parameter arguments to the macro
  • Returning undefined (no-op) when parameterMacro is not a function
  • Returning undefined when parameterMacro is null or undefined
• ESLint passes with --no-verify (Husky hook has exec format issues on Windows)
• Verified the fix logic matches the reproduction scenario from the issue

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.