Align magic login confirmation layout

[chriskmnds]

Part of https://linear.app/a8c/issue/DSGCOM-153/login-magic-code-on-confirm-page-update-footer-to-a-tertiary-resend

Proposed Changes

• Extend OneLoginFooter to accept optional children and adjust its styles so inline paragraphs can share the same typography and link treatments as the other login views.
• Swap the custom Jetpack confirmation footers for OneLoginFooter, remove bespoke classes, and wrap the forms so the padding/margins match the request page.
• Restore the missing spacing on .magic-login__successfully-jetpack so the confirmation cards keep the same bottom margin and padding as .form-fieldset / .card.logged-out-form.

Before	After	Code/main screen

Why are these changes being made?

• The confirmation pages had drifted from the primary login layout, resulting in misaligned typography, colors, and spacing. Syncing them with OneLoginFooter keeps every login step visually consistent and avoids one-off Jetpack-only styles.

Testing Instructions

• Visit /log-in/link and /log-in/jetpack/link, trigger the confirmation flow, and confirm the footers render as a single paragraph with consistent fonts/colors and default link hover behavior.
• Verify the code confirmation and Jetpack connect success pages now share the same margins/padding as the request page (no footer touching the form, links centered, matching font sizes).
• Verify that footer links in the main Login pages, like "forgot password" or "use a password instead", have not been affected by the changes

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you tested accessibility for your changes? (PCYsg-S3g-p2)
• Have you used memoizing on expensive computations?
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages?
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this PR changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-162433

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-162433&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-162433&env=a8c-for-agencies

[matticbot]

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

• help-center

To test WordPress.com changes, run install-plugin.sh $pluginSlug unify/magic-login-layout on your sandbox.

[chriskmnds]

@jasmussen this is a follow-up to my comment in #107130 (comment)

It aligns the footer text used in the code confirmation pages to match structurally with the remaining footers in other Login pages. The link colors no longer apply the Jetpack palette (or other palettes when magic code is ported to other OAuth clients). If we want to bring that back, then we can do so. I recall a discussion about links in the footer and sub-header or the top-bar not to be colored or accented. It's the same color variation used in the sub-header now.

Do you mind taking a look and letting me know what works? :-)

[jasmussen]

Thanks for the ping. Jetpack looks great for anyone who might glance at this, and wonder: why remove the spot color from links? If I recall correctly, it's because other consumers, like Blaze, uses an orange color that would not meet text contrast in that context, so keeping them all a single color provides a uniform legible baseline.

If I remembered that right, then on principle this seems fine to me, even if I will be missing the green links a little bit, but no strong opinions.

One thing though, the font weight change. I don't think we're changing the font weight on links in the broader system, they still have the same weight as the surrounding text, they're just underlined. It's possible there's a decision somewhere that introduced it, I'd love that context if possible. But absent that, I think we should omit the font weight change, keep it simple.

One more thing:

		color: var( --studio-wordpress-blue, #3858e9 );

I believe "wordpress-blue" has been deprecated in Studio, because it's meant to be the default blue. So you should be able to just use --studio-blue.

[chriskmnds]

Thanks @jasmussen . Yes, I recall same convo. Also that we'd want to not highlight things outside the main form controls/CTA. But if the green/JP color is subtle here and we want to bring it back, an exception, then happy to do that. Otherwise I will proceed like you mentioned.

One thing though, the font weight change. I don't think we're changing the font weight on links in the broader system, they still have the same weight as the surrounding text, they're just underlined. It's possible there's a decision somewhere that introduced it, I'd love that context if possible. But absent that, I think we should omit the font weight change, keep it simple.

Will do! It was my guess, seeing as we have bolder font when it's only a single link, like "lost password" or "use a password instead".

I will nudge you back in a bit with the changes. Thanks!

[jasmussen]

Let's see if @keoshi has instincts, otherwise I'd move forward.

[chriskmnds]

Ok. Thanks again @jasmussen . I think it should all be addressed now. I also spotted one inconsistency that has been fixed now (the font size on the first link was smaller than the rest). So this is how it looks with the latest changes:

p.s. We also fixed the login link confirmation page, which was not properly aligned either. Text had a different color and decorations:

Before	Before Hover	After

One more thing:

		color: var( --studio-wordpress-blue, #3858e9 );

I believe "wordpress-blue" has been deprecated in Studio, because it's meant to be the default blue. So you should be able to just use --studio-blue.

Ah. This was leftover code that I've completely removed now.

Let me know if you spot anything else or anything to change. Otherwise, will wait for @keoshi :-)

[keoshi]

Thanks for the ping! Change looks good to me in the context of cohesion between all login screens.

The only thing I see (and it might just be the screenshots above tricking my eyes) is that the color of the accessory text seems a tad lighter than the one in Code/main screen. Ignore me if it was globally updated recently or if I'm wrong.

[chriskmnds]

Thanks @keoshi !

Thanks for the ping! Change looks good to me in the context of cohesion between all login screens.

The only thing I see (and it might just be the screenshots above tricking my eyes) is that the color of the accessory text seems a tad lighter than the one in Code/main screen. Ignore me if it was globally updated recently or if I'm wrong.

Hmm not that I recall. We can update them if something feels better. Currently subheader and footer are var( --studio-gray-50, #646970 ). We also have a secondary subheader that is --studio-gray-30 e.g. in Woo JPC (this still needs a smaller header font):

[chriskmnds]

The only thing I see (and it might just be the screenshots above tricking my eyes) is that the color of the accessory text seems a tad lighter than the one in Code/main screen. Ignore me if it was globally updated recently or if I'm wrong.

Or did you mean the "Email address or username" label above the input field? That is indeed lighter than the main page. Main login has --color-neutral-100, magic login --studio-gray-60. I'm guessing we should sync/update these, no?

Main	Lost Password	Magic Link

@jasmussen @keoshi