[SUR-488] Fix borderless reverse-position radio/switch alignment

[jaieds]

Summary

PR #471 added reverse-position support for the bordered radio-button variant, but the new geometry applied to every reversePosition usage:

• the control moved from flush left-0 to left-3 ml-0.5 (~14px inset)
• the wrapper gained pl-16/pl-12 padding

For borderless reversed usage — e.g. the SureEmails onboarding template's useSwitch + reversePosition opt-in — this shifted the switch right and misaligned it with surrounding form fields.

Fix

Scope the inset geometry to borderOn. Without a border, the legacy layout is restored: control flush at left-0, content offset via ml-10 (switch) / ml-4 (radio). The nested ternary is extracted into a controlPositionClass variable to satisfy no-nested-ternary.

Case	Before this PR	After
reversePosition + borderOn	control inset 14px (intended)	unchanged
reversePosition borderless	control inset 14px (regression)	flush left (pre-#471 layout)
default (not reversed)	unchanged	unchanged

Testing

• Templates/Onboarding/Spam story: switch left edge aligns with the field above again
• Atoms/RadioButton bordered reverse-position stories (radio + switch): inset intact
• eslint, tsc -b, and radio-button storybook interaction tests pass

[github-actions]

What: The addition of comments explaining the layout differences is useful, but consider also documenting how the controlPositionClass and controlSpacingClass are determined as they add some complexity.

Why: Clear documentation within the code helps current and future developers understand the layout logic and aids in maintenance, especially in component libraries where multiple developers may be involved.

How: You may enhance the comments to explain the conditions for borderOn and reversePosition affecting layout, and include a brief on the expected outcomes of each combination.

[github-actions]

What: While updating the dependencies in the useEffect hook for reversePosition, borderOn, and useSwitch is beneficial, ensure that changes in these dependencies do not lead to unnecessary renders.

Why: Adding more dependencies to the useEffect may cause performance overhead if they frequently change and result in excessive re-renders. Optimize the state management logic to minimize updates where possible.

How: Evaluate if all added dependencies are vital for the side effects you are triggering. If some, like borderOn or useSwitch, are not frequently changing during component lifecycles, consider managing them with either state or derived state.