`_generated/server.ts` reads `process.env` at module scope, breaking every convex-test suite on the `edge-runtime` environment

`src/component/_generated/server.ts:123` evaluates `process.env` at module top level:

```ts
export const env: Env = process.env as unknown as Env;
```

Under `convex-test`, component modules are registered via `import.meta.glob` and evaluated lazily by Vitest's module runner the first time a component function runs. In a suite using `environment: "edge-runtime"` (the standard choice for Convex backend tests, since it approximates the Convex runtime), `process` is not a resolvable binding in that scope, so the module throws on evaluation:

```
Error: ReferenceError: process is not defined
at .../@convex-dev/batch-worker/src/component/_generated/server.ts:123:25
at VitestModuleEvaluator._runInlinedModule (vitest/dist/module-evaluator.js:206:4)
at VitestModuleRunner.directRequest (vite/dist/node/module-runner.js:1259:59)
at VitestModuleRunner.cachedRequest (vite/dist/node/module-runner.js:1166:73)
at .../@convex-dev/batch-worker/src/component/lib.ts:2:1
at convex-test/dist/index.js:1366:16
at performAsyncSyscall (convex/src/server/impl/syscall.ts:52:10)
```

The failure surfaces to the caller as an opaque `process is not defined` from whatever enqueued the work, with no mention of batch-worker.

## Why this is newly reachable

`@convex-dev/workpool` 0.4.9 moved its main loop onto this component, so every workpool user with a convex-test suite now loads it. Workpool's own `component/_generated/server.ts` has no `process.env` line, which is why this never came up before. Notably `process` *is* resolvable in ordinary test-file scope in the same environment — `typeof globalThis.process === "object"` passes — so this is specific to how component modules get evaluated, not a blanket absence of `process`.

## Impact

In our repo (2000 tests), taking workpool 0.4.9 produced **105 failures** across 11 files, all tracing to this one line. We pinned workpool back to 0.4.8.

## Verification

Editing just that line in `node_modules` takes the suite from 105 failures to 0:

```ts
export const env: Env = (((globalThis as any).process?.env) ?? {}) as unknown as Env;
```

Both halves matter. With `process?.env` alone, `env` is `undefined` and the suite still fails — differently: 4 tests fail on assertions rather than throwing, because the batch-worker loop silently stops making progress once something reads a property off `undefined`. Defaulting to `{}` is what actually makes it green. So whatever fix you pick, `env` should end up an object even when no environment is available.

## Environment

| | |
|---|---|
| `@convex-dev/batch-worker` | 0.2.0 |
| `@convex-dev/workpool` | 0.4.9 |
| `convex` | 1.43.0 |
| `convex-test` | 0.0.55 |
| `vitest` | 4.1.10 (`environment: "edge-runtime"`) |
| node | 24.16.0 |

## Possibly separate, possibly intended

`dist/component/convex.config.js` imports `./logging` without a file extension while the package is `"type": "module"`. `dist/component/logging.js` exists, so the Convex bundler resolves it fine, but Node's native ESM loader cannot:

```
Cannot find module '.../@convex-dev/batch-worker/dist/component/logging'
imported from '.../@convex-dev/batch-worker/dist/component/convex.config.js'
```

Flagging in case that path is meant to be Node-loadable; ignore if the bundler is the only intended consumer.

Start at src/component/_generated/server.ts:123 and reproduce the failure with convex-test under Vitest's edge-runtime environment. Verify the change against the affected suite and confirm that the generated env value remains an object when process is unavailable, taking the separate dist/component/convex.config.js ESM import issue only if it is in scope.

Written by the indexing model from the issue text.