fix(style): add gap to auth button wrapper for improved layout

[alexechoi]

Description

Move the gap spacing for auth action buttons from an inline style in auths.jsx to the existing .auth-btn-wrapper class in _authorize.scss. This ensures consistent button spacing across all auth dialogs (both non-OAuth and OAuth2) and follows the project's convention of using SCSS stylesheets over inline styles.

Motivation and Context

Current state

The authorize/logout and close buttons in the auth modal had no spacing between them. A gap: 10px was added as an inline style in auths.jsx, but this only fixed the non-OAuth auth dialog and didn't follow the repo's styling convention. Moving it to the SCSS stylesheet fixes the spacing for all usages of .auth-btn-wrapper, including the OAuth2 dialog in oauth2.jsx.

How Has This Been Tested?

• Verified that the .auth-btn-wrapper class is used in both auths.jsx and oauth2.jsx
• Confirmed no other inline styles exist in the auth components
• Confirmed the SCSS rule already has display: flex, so gap applies correctly
• Tested ads per the below screenshot

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.

This is a simple UI improvement so does not need any additional tests