fix(deploy): make bun run dev:server start and reach its settings

Two defects, both found by running it. Neither affects the container path,
which is why the images passed: they run the same entrypoints from the
repository root, and that turns out to be the load-bearing detail.

**The issuer would not start at all.** `apps/auth/tsconfig.json` named
React as the JSX runtime — left over from an earlier scaffold; there is no
React anywhere in this repository. It only bit when something transpiled
from that directory, and then the process died resolving
`react/jsx-dev-runtime` from a sign-in screen in `packages/auth` before it
bound a port. The package holding those components already said `hono/jsx`,
and so did the root; this is the third place agreeing with them.

**Neither process could see `.env`.** They ran with the working directory
set to their own app, so the environment file the repository documents —
the one at the root — was not the one they were offered. The issuer then
correctly refused to send a sign-in code rather than logging one, which is
the right behaviour and an opaque way to discover a path problem. Both now
run from the root, which is also exactly what the images run.

apps/auth/tsconfig.json

@@ -4,8 +4,14 @@
 	"compilerOptions": {
 		"module": "ESNext",
 		"moduleResolution": "bundler",
-		"jsx": "preserve",
-		"jsxImportSource": "react",
+		// The sign-in screens are `hono/jsx`, and there is no React in this
+		// repository at all. Naming React here was left over from an earlier
+		// scaffold and only bit when something transpiled from this directory:
+		// `bun run serve` resolved `react/jsx-dev-runtime` from a component in
+		// `packages/auth` and stopped before the server bound a port. The
+		// package holding the components already says this; so does the root.
+		"jsx": "react-jsx",
+		"jsxImportSource": "hono/jsx",
 		"types": ["@cloudflare/workers-types", "node", "bun"]
 	}
 }