User makes an address optional for everyone, when only a service account lacks one

[mroops0111]

User describes two different things with one shape, and the shape fits neither.

export const User = z.object({
  id: UserId,
  googleSub: z.string().min(1).optional(),
  email: z.string().email().optional(),
  displayName: z.string().min(1),
  serverRole: ServerRole.default('user'),
  kind: UserKind.optional(),
  createdAt: Timestamp,
})

A person who signs in through Google always has an address and a subject. A service account, the reactor being the one in the tree, has neither and never will. Marking both optional says every combination is legal, including a user with a googleSub and no email, which cannot happen and which nothing rejects.

What it costs

Eleven places re-derive at runtime what the type could have guaranteed:

packages/server/src/infrastructure/oauth/GoogleOAuth.ts:192
packages/server/src/infrastructure/oidc/OidcTokenVerifier.ts:119
packages/server/src/infrastructure/users/autoJoinGuests.ts:45
packages/server/src/infrastructure/users/autoJoinGuests.ts:67
packages/server/src/infrastructure/users/UserDirectoryFromRegistry.ts:19
packages/server/src/infrastructure/users/UserRegistryFile.ts:42
packages/server/src/routes/admin.ts:274
packages/server/src/authMode.ts:65
packages/core/src/application/HistoryService.ts:95
packages/core/src/application/enrichCommitAuthor.ts:23
packages/studio/src/components/WorkspaceDetailsSheet.tsx:1035

Each is a ?., a ??, or an if, and each one is a small decision about what an absent address means, taken separately. The type says "may be missing" without saying when, so every reader has to work out the when for themselves.

This surfaced while writing the domain admission in #156. The type caught an assumption that every user has an address, which was the right catch, but it offered no way to say "every user who signs in does".

Shape of a fix

A discriminated union on kind says it directly:

const HumanUser = z.object({
  kind: z.literal('human'),
  googleSub: z.string().min(1),
  email: z.string().email(),
  ...
})

const ServiceUser = z.object({
  kind: z.literal('service'),
  ...
})

export const User = z.discriminatedUnion('kind', [HumanUser, ServiceUser])

A signed-in user without an address stops being expressible. Most of the eleven guards disappear, and the ones that remain read as user.kind === 'service', which is the question they were always asking.

Why this is not small

kind is optional today, and its comment says absent means human, so existing user records carry no discriminant at all. The change needs a migration that stamps kind onto them before anything reads the union, plus UserCreate, UserRegistryFile, and the admin routes moving with it.

Worth doing on its own rather than riding along with a feature, since a reviewer should see the migration and the guard removals together.