Accessibility: Easier to access Authorization

[hariswhdn]

Description

This PR introduces three specific CSS enhancements to the Swagger UI layout:

1. Sticky Navbar: The .scheme-container (containing the Authorize button) is now sticky at the top of the viewport.
2. Reduced Height: Decreased the vertical padding of the navbar from 30px to 15px to save screen real estate.
3. Softer Overlay: Reduced the modal backdrop opacity from 0.8 to 0.5 for a less aggressive visual transition.
4. Layout Alignment: Changed the schema label to a row-based layout with a 10px gap for better alignment.

Motivation and Context

The primary goal is to improve the developer experience during frequent testing:

• Making the navbar sticky ensures the Authorize button is always accessible, removing the need to scroll back to the top to update tokens.
• Reducing the height prevents the sticky element from occupying too much vertical space.
• The softer backdrop improves UI modernness and visibility of the underlying context.

How Has This Been Tested?

• Environment: Chrome/Edge/Firefox on Windows 10.
• Manual Test: Scrolled through long API definitions to verify the navbar remains fixed at top: 0.
• Visual Check: Confirmed that the "Authorize" modal backdrop is more transparent and the label alignment remains centered.

Screenshots (if appropriate):

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.