gateway ui: fix People.tsx type error that broke the v0.4.262 image build

[Evanfeenstra]

What

The v0.4.262 release build (publish-gateway.yml, run 35023442898, commit 588afcb) failed in the plugin-ui-builder stage on code from #1694:

src/pages/People.tsx(123,40): error TS2339: Property 'get' does not exist on type 'RevokeUsersResponse | Map<string, string>'.
src/pages/People.tsx(142,38): error TS2339: Property 'has' does not exist on type 'RevokeUsersResponse | Map<string, string>'.

Two commits:

1. The narrowing fix. The useMemo that maps revoked users to their cutoff relied on if (!revoked.data) return revoked.data narrowing the TanStack query result's data through a truthiness check. It now binds revoked.data to a local const, tests undefined and null explicitly, and annotates the memo's return type, so the result is Map | null | undefined regardless of how useQuery's result type is resolved.

2. Commit the SPA lockfile. The root .gitignore ignored package-lock.json repo-wide (the rest of the monorepo is yarn), so the gateway SPA resolved its dependencies fresh on every image build: the Dockerfile's npm ci branch never ran, gateway-check.yml keyed its cache on package.json, and ui/AGENTS.md claimed a lockfile that wasn't there. This un-ignores and commits it, keys the CI cache on it, and makes make ui-install (the CI target) npm ci. The Dockerfile already switches to npm ci when the file is present. From here, local, gateway-check.yml, and the release image all install the identical tree.

Reproduction status

I could not reproduce the failure outside the release job. The unfixed code type-checks clean with: the local node_modules; a fresh npm install on macOS; node:22-alpine on Linux; and the exact node:25-alpine3.23 image on linux/amd64 (npm 11.12.1), which resolves the same react-query 5.102.8 / TS 5.6.3 / preact 10.29.8 the registry serves today (nothing in that set has been published since Aug 27). I don't have an explanation for why the release runner's npm install produced a different result. The two changes above are safe either way: the fix does not depend on the narrowing that differed, and the lockfile removes the fresh-resolution variable from future builds.

Verified

• npm run typecheck and npm run build clean in the repo.
• npm ci from the committed lockfile plus npm run build in node:22-alpine on Linux (platform-specific esbuild/rollup optional packages resolve).
• go/tygo untouched.