refactor(auth): serve one provider, and make it the email one

Signing in with a gaming account or with an SSH key could both bring a
user into existence. That makes an account only as recoverable as the
thing that created it, and gives one person as many accounts as they
have gaming logins — neither of which is what an account is supposed to
be now that verifying an address is what creates one.

Both are unwired rather than deleted. The provider implementations stay
where they are, because connecting a gaming account is still something
this product does; it just does it from the API, against a user who
already exists, which is a connection hanging off an identity rather
than an identity of its own.

The worker test followed: it exercised the two flows that are gone, and
now covers the one that is left plus an assertion that the other two are
not routed, so they cannot come back quietly.

alchemy.run.ts

@@ -5,7 +5,6 @@ import { Redacted } from 'effect';
 import * as Effect from 'effect/Effect';
 
 const steamApiKey = Redacted.make(process.env.STEAM_API_KEY!);
-const sshAuthKey = process.env.SSH_AUTH_KEY || 'dev-ssh-auth-key-change-in-prod';
 const adminSharedSecret =
 	process.env.ADMIN_SHARED_SECRET || 'dev-admin-shared-secret-change-in-prod';
 
@@ -41,11 +40,12 @@ export const Auth = Effect.gen(function* () {
 	return yield* Cloudflare.Worker('auth', {
 		main: 'apps/auth/src/index.ts',
 		compatibility: { flags: ['nodejs_compat'] },
+		// No Steam or SSH settings: the issuer serves one provider, and it is
+		// the email one. Linking a Steam account is `apps/api`'s job and its
+		// key is bound there.
 		env: {
 			AuthStorage,
-			HYPERDRIVE: Database,
-			STEAM_API_KEY: steamApiKey,
-			SSH_AUTH_KEY: sshAuthKey
+			HYPERDRIVE: Database
 		},
 		...(isPermanent ? { observability: { enabled: true } } : {})
 	});