feat(ux): separate server response and possible responses into distinct panels

[yscialom]

Description

After executing a "Try It Out" request, the actual server response and the documented possible responses were visually indistinguishable, forcing users to mentally parse the layout on every use.

This PR introduces clear visual separation between the two:

• Rename the "Responses" label to "Possible responses" when a server response is present, to distinguish it from the actual response.
• Wrap each section's table in its own panel with a light grey background (.server-response-panel and .possible-responses-wrapper).
• Increase the .responses-inner h4 title size from 12px to 14px so section titles ("Server response", "Possible responses") stand out from table content.
• Add a dark mode override for the panel backgrounds.

Motivation and Context

Fixes #6548

The issue requested making the "Server response" / "Responses" titles more prominent and visually grouping the documented responses into their own sub-panel, so users can immediately tell apart what the server actually returned from what the API documents as possible.

Note on scope: the .responses-inner h4 size bump also applies to the "Request URL" heading inside the live response. This is intentional and kept consistent — documented inline in _layout.scss.

How Has This Been Tested?

• npm run test:unit — all suites pass, including new unit tests for the Responses component covering the conditional "Possible responses" heading and the .possible-responses-wrapper.
• npm run lint-errors — zero errors.
• npm run build — all bundles compile.
• Manual testing in the dev server (port 3200) with OAS 2.0 and OAS 3.x specs, in both light and dark mode, before and after executing a request.

A legacy Selenium selector in test/e2e-selenium/scenarios/oas3/pet.js was updated to account for the removed wrapper <div> around LiveResponse.

Screenshots

Screenshot showing the separated "Server response" and "Possible responses" panels (to be attached):

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.

Usage of AI

Claude Opus 4.8 & Sonnet 4.6 was used for the following parts of this contribution:

• Initial analysis of the codebase to locate the relevant components and styles.
• Code reviews of the changes hand-written by the author.
• Writing the unit test(s).
• Writing the commit messages and the text of this pull request.

The core implementation was written by hand by the author.