fix(seed): emit the users array the backend seeder reads

The fixture generator was a version behind the seeder, and the gap was
the `users` key.

`internal/seeder` unmarshals `seed.json` into `{demoUser, users,
entities}` and writes every account in `users`, falling back to
`demoUser` alone when the key is absent. `fixtureFrom` never emitted it —
its comment still claimed the Go loader "ignores the rest", which stopped
being true when the seeder gained the field. So `npm run seed:check`
reported stale on every run, and that is the seventh suite failure, the
one that pre-dates the TypeScript migration.

What made this worth investigating rather than regenerating: the
committed fixture was NOT wrong. It carries two accounts — the demo
administrator and `employer@krow.app` — and running `npm run seed:fixture`
against the old generator would have written a fixture without them.
`krow-backend/docs/deploy-9d3192a.md` says so in as many words, and tells
anyone deploying not to run it.

The accounts are not deleted from a live database by that — the only
DELETE in the seeder is the shift-record prune, and `upsertUser`'s ON
CONFLICT deliberately leaves `password_hash` alone. The damage lands on
the next fresh environment, where `user_employer` would simply never be
created, leaving nobody to sign in as to reach the employer console —
which is the exact gap `seeder.go` records the account as having been
added to close.

The matching frontend half already existed, unmerged, on
`feat/krow-employee-pages` (7a4b61d). That branch is a 53-file console
restructure that renames the same files this migration renamed, so it is
not mergeable here. Only the three files that carry the contract are
taken: `EMPLOYER_USER`, `seedData.User` naming both accounts, and the
generator emitting `users`.

The proof is that nothing had to be written. With the generator corrected
its output is byte-identical to the fixture already committed in
krow-backend — 168,293 bytes, `cmp` clean — so `seed.json` was never
opened for writing, and its md5 and mtime are untouched.

  typecheck     0 errors
  seed:check    "seed.json is in step with src/api/seed.js", exit 0
  npm test      1685/1691, up from 1684 — the fixture check now reads
                "24 applications, byte-identical". The remaining 6 are
                exactly the documented dca1842 baseline failures.
  lint          exit 0, 0 errors, 289 warnings
  build         exit 0, bundle 74d17e2d… unchanged

The bundle being unchanged is itself a check: `demoUser.ts` IS in the
production bundle, and `EMPLOYER_USER` is a new export of it. Nothing in
the app imports it, so it is tree-shaken out and not one byte reaches the
shipped code.

No baseline artifact touched. krow-backend not modified.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HBG1wnuRfJKCstGB8Fekr8

scripts/seed-fixture.mjs

@@ -31,10 +31,31 @@ export const GENERATED_NOTE =
 
 export function fixtureFrom(seedModule) {
   const { ShiftRecord, ...entities } = seedModule.seedData;
-  /* First key, so it is the first thing anyone opening the file reads. The Go
-     loader unmarshals into a struct of demoUser + entities and ignores the
-     rest, so this costs nothing on the reading side. */
-  return { _generated: GENERATED_NOTE, demoUser: seedModule.DEMO_USER, entities };
+  /* `_generated` first, so it is the first thing anyone opening the file reads.
+
+     `users` is the channel the seeder actually reads — `internal/seeder`
+     unmarshals into `{demoUser, users, entities}` and writes every account in
+     `users`, falling back to `demoUser` alone when the key is absent. That
+     fallback is why `demoUser` stays beside it rather than being replaced: a
+     fixture written here still seeds correctly against a backend that predates
+     the list, it simply seeds one account instead of two.
+
+     Emitting only `demoUser` is what this generator used to do, and it was a
+     version behind: the fixture on disk carries the employer account, the
+     seeder reads it from `users`, and regenerating without this key would drop
+     `employer@krow.app` from every fresh seed — leaving nobody to sign in as
+     to reach the employer console, which is the exact gap the account was
+     added to close.
+
+     `entities.User` carries the same list. The seeder ignores it, and it is
+     emitted because `seedData` is copied wholesale; the two are the same array
+     rather than two places to keep in step. */
+  return {
+    _generated: GENERATED_NOTE,
+    demoUser: seedModule.DEMO_USER,
+    users: seedModule.seedData.User,
+    entities,
+  };
 }
 
 /** Serialised exactly as the committed file is: 2-space indent, no trailing newline. */