refactor(auth): describe sign-in screens as data, draw them in one place

Providers no longer return a `Response`. Each one says what it needs from
the person — an address, a pin, a yes-or-no — as a `Screen`, and a single
`Renderer` decides how that is drawn.

The old arrangement made every provider a small web framework. It had to
know about markup, about the stylesheet's attribute names, about how a page
is assembled, so each grew its own callback signature and its own copy of
`new Response(jsx.toString())`. Three consequences, all of them visible in
the tree before this change:

- The device flow never got a design at all. Its two pages were built by
  concatenating HTML strings, with an inline `style` on the user code, and
  six of its replies were `text/plain` — unstyled black-on-white in the
  middle of signing in, which is also what a person got when their sign-in
  cookie expired.
- The password screens were drifting. They were written against attribute
  names the stylesheet no longer had, and nobody noticed because password
  sign-in is not switched on. They are deleted here rather than repaired;
  the flow is now six screen descriptions and no markup.
- A provider could not be named or marked without editing the library. The
  brand marks and display names were two hardcoded records inside the code
  that drew the chooser, so anything missing from them rendered as its own
  lowercase identifier with no icon. Providers now declare `display`
  themselves, and the chooser is built from what they say.

Also removes the theme global. It was `globalThis`, with a comment
conceding as much, which made every component depend on something invisible
at the call site — untestable in isolation, and shared mutable state on a
runtime that keeps one module instance across requests. The theme is now a
closure argument, and the same change shrinks `Theme` to the handful of
values a deployment sets that the stylesheet cannot.

Adding a screen now touches no CSS, and swapping the presentation layer
means implementing one method. The code flow's tests demonstrate the
second: they render screens as JSON.

Behaviour is unchanged. Status codes, cookies and the confirmation step are
the same, which the device tests cover unmodified.

packages/auth/test/code.test.ts

@@ -15,17 +15,22 @@ const auth = issuer({
 	storage: MemoryStorage(),
 	subjects,
 	allow: async () => true,
+	// Screens back as JSON instead of HTML, which is the whole of what it takes
+	// to replace the presentation layer — and is why these tests can assert on
+	// what the flow decided rather than on the markup it happened to produce.
+	renderer: { render: (screen) => Response.json(screen) },
 	providers: {
 		code: CodeProvider({
 			maxAttempts: 3,
 			maxSends: 2,
 			sendWindow: 3600,
 			resendInterval: 0,
-			request: async (_req, _state, _form, error) =>
-				new Response(JSON.stringify({ error: error?.type ?? null }), {
-					status: 200,
-					headers: { 'content-type': 'application/json' }
-				}),
+			request: async (_req, _state, _form, error) => ({
+				kind: 'message',
+				tone: 'danger',
+				heading: error?.type ?? 'none',
+				body: []
+			}),
 			sendCode: async (claims, code) => {
 				if (!claims.email?.includes('@')) {
 					return { type: 'invalid_claim', key: 'email', value: claims.email ?? '' };
@@ -92,7 +97,8 @@ async function ask(email: string) {
 
 /** What the stub UI reported, so a test can name the error rather than a status. */
 async function errorOf(response: Response) {
-	return ((await response.clone().json()) as { error: string | null }).error;
+	const screen = (await response.clone().json()) as { heading: string };
+	return screen.heading === 'none' ? null : screen.heading;
 }
 
 beforeEach(() => {