fix(oas3): reverse readOnly/writeOnly handling for callback request bodies

[maruthang]

Description

Added isCallback prop to the RequestBody component, detected by checking if specPath includes "callbacks" in the Parameters component. When isCallback is true, the readOnly/writeOnly behavior is reversed across all 5 relevant places in request-body.jsx:

1. Sample generation (getDefaultRequestBodyValue): uses includeReadOnly: true instead of includeWriteOnly: true
2. Form field filtering: shows readOnly properties and hides writeOnly properties (opposite of normal behavior)
3. Initial value generation: uses includeReadOnly: true instead of includeWriteOnly: true
4. Sample request body: passes isCallback to getDefaultRequestBodyValue
5. ModelExample component: sets includeReadOnly={true} and includeWriteOnly={false} for callbacks

Motivation and Context

Fixes #6294

Callback request bodies are sent by the API to the consumer, not by the consumer to the API. This means:

• readOnly properties (managed by the API) should be included in callback request bodies, since the API is the sender
• writeOnly properties (user secrets like passwords) should be excluded from callback request bodies, since the API should not send these back

Previously, Swagger UI treated callback request bodies the same as regular request bodies, incorrectly omitting readOnly and including writeOnly properties.

How Has This Been Tested?

• Added 3 unit tests in test/unit/core/plugins/oas3/request-body.js:
  • Verifies getDefaultRequestBodyValue uses includeWriteOnly for regular requests
  • Verifies getDefaultRequestBodyValue uses includeReadOnly for callback requests
  • Verifies default isCallback parameter is false when not provided
• All 832 existing unit tests continue to pass
• ESLint passes with zero warnings

Screenshots (if appropriate):

N/A - Logic-only change, no visual 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.