fix(operation): recognize wildcard HTTP status codes as documented responses

[yogeshwaran-c]

Description

When an OpenAPI spec defines responses using HTTP status code ranges like 4XX or 5XX, individual status codes within that range (e.g., 401, 404, 500) were being incorrectly marked as "Undocumented" in the live response section.

The existing check in operation.jsx only matched exact status code strings (e.g., "401") and the "default" key. This change adds a fallback check for range patterns (1XX, 2XX, 3XX, 4XX, 5XX) as defined in the OpenAPI specification.

Motivation and Context

Fixes #6175

The OpenAPI specification supports HTTP status code ranges using patterns like 4XX (see describing-responses). When a server returns a 401 response and the spec defines 4XX, the response should be recognized as documented.

How Has This Been Tested?

• Verified the logic correctly computes the range pattern (e.g., "401" -> "4XX")
• Tested edge cases: exact match takes precedence, range match used as fallback, and "default" still works as final fallback
• Status codes that don't match any pattern are still correctly marked as undocumented

Screenshots (if appropriate):

N/A - logic change only

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.