fix(oas3): apply default encoding for form-urlencoded array properties

[maruthang]

Description

Added an afterLoad hook to the OAS3 plugin that wraps fn.buildRequest. Before calling the original buildRequest, it inspects the spec and for any application/x-www-form-urlencoded media type with array properties that lack explicit encoding, it adds the OAS3 default encoding (style: "form", explode: true). This ensures arrays serialize as numbers=1&numbers=2&numbers=3 instead of numbers=1,2,3.

Motivation and Context

Fixes #7695

When encoding is omitted for application/x-www-form-urlencoded request body array properties, Swagger UI used comma-separated values (numbers=1,2,3) instead of the OAS3 default exploded format (numbers=1&numbers=2&numbers=3). Per the OpenAPI 3.0 specification, the default serialization for form data is style: form with explode: true, which means each array element should be sent as a separate key-value pair.

How Has This Been Tested?

• Added 5 regression tests in test/unit/core/plugins/oas3/after-load.js covering:
  1. Default encoding applied for array properties when encoding is omitted
  2. Existing explicit encoding is preserved and not overridden
  3. Non-array properties are not affected
  4. Non-form-urlencoded content types are not affected
  5. Mixed properties (arrays and non-arrays) are handled correctly
• All 834 existing unit tests pass
• Lint passes

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.