fix: accept process.env in worker options

[cqxswbc2]

Closes #136

Summary

• widen the public env option from Record<string, string> to NodeJS.ProcessEnv
• keep the internal worker interface aligned with the public option type
• add a regression test that passes process.env directly to a worker

This deliberately does not add SHARE_ENV support because Tinypool also supports the child_process runtime, where that worker-thread-only symbol is not accepted.

Validation

• pnpm build
• pnpm typecheck
• pnpm lint
• pnpm exec vitest run test/simple.test.ts (26 passed)
• pnpm exec vitest run test/termination.test.ts (3 passed)

The full test command was also attempted on Windows with Node 24. It reached 87 passing tests before a Vitest child process hit a heap OOM and one termination test timed out; that termination file passed when rerun in isolation.

[AriPerkkio]

Does this allow passing SHARE_ENV from import { SHARE_ENV } from 'node:worker_threads' too?

[cqxswbc2]

No. This PR deliberately only accepts process.env.

SHARE_ENV is specific to worker_threads, while Tinypool exposes the same env option for child_process. Admitting the symbol in the shared type would also require runtime validation (including the recycleWorkers({ runtime: "child_process" }) path); otherwise the process worker's object spread would turn the symbol into an empty environment.

#138 explores that larger feature and its guards. If you prefer full WorkerOptions["env"] parity, I can expand this PR with the runtime checks and tests. Otherwise, I think keeping #137 scoped to the process.env type mismatch is the safer minimal change.