Sign-in colour palette diverges across auth-service routes

[aspiers]

packages/auth-service/src/routes/login-page.ts defines a :root token set (--muted-foreground: #666, --card-bg, --page-bg, --focus-border, …) and styles .btn-secondary through it. account-login.ts and recovery.ts define no tokens at all and hardcode their own palette:

	.btn-secondary	:hover
login-page.ts	var(--muted-foreground) → #666	#1A130F
account-login.ts	#0f1828	#000
recovery.ts	#0f1828	#000

Consequences:

• the same action is a different colour depending on which sign-in screen you are on;
• a trusted client's branding.css override of --muted-foreground reaches only the login page.

Not a one-line fix

Raised by CodeRabbit reviewing #237, which proposed var(--muted-foreground, #0f1828) in the two route-local files. That would not work as intended: neither file defines the token, so it resolves to the fallback on every unbranded deployment — changing nothing, while appearing to wire up theming. It would take effect only under a branding.css override, and would then apply a colour chosen against the login page's palette to pages that do not share it.

Doing it properly means deciding whether account-login.ts and recovery.ts should adopt the login page's token set wholesale, and reconciling the two palettes.

Not an accessibility problem

Both values clear WCAG AA on white — #0f1828 at 17.77:1 and #666 at 5.74:1. This is a consistency issue, not a contrast one.

Related

Same three routes diverging on a different axis: #238 (the OTP forms themselves are structurally different).

Acceptance

One documented token set shared by all three sign-in surfaces, or an explicit recorded decision that they are intentionally separate.