fix(code-runtime): reject a maxWallMs above Node's maximum timer delay

`config.maxWallMs` is only checked for positivity, and it is handed to
`setTimeout`, which clamps any delay above 2^31-1 ms to 1 ms. A deployment
configuring a 25-day wall ceiling therefore gets the opposite of what it asked
for: every run times out on the first tick. The runtime now range-checks the
field at load against MAX_TIMER_DELAY_MS from dsh-timeout and throws, so the
misconfiguration fails loud where it is self-contained instead of silently
inverting the budget.

`computeMs` needs no matching bound: it is compared against measured event-loop
utilization rather than fed to a timer.

The test asserts both the rejection and that the boundary value itself loads.

packages/code-runtime/code-runtime-worker/tests/runtime.spec.ts

@@ -829,6 +829,16 @@ describe('WorkerCodeRuntime — seam misuse and lifecycle', () => {
     await expect(ctx.plugin(WorkerCodeRuntime, { computeMs: -1 })).rejects.toThrow(/positive number/)
   })
 
+  it('rejects a maxWallMs above Node\'s maximum timer delay', async () => {
+    // setTimeout clamps a delay past 2^31-1 ms to 1 ms, so the positivity check
+    // alone would accept a 25-day ceiling that expires on the first tick.
+    const ctx = new Context()
+    await expect(ctx.plugin(WorkerCodeRuntime, { maxWallMs: 2_147_483_648 }))
+      .rejects.toThrow(/maxWallMs must be at most 2147483647/)
+    // The boundary itself is usable.
+    await expect(ctx.plugin(WorkerCodeRuntime, { maxWallMs: 2_147_483_647 })).resolves.toBeTruthy()
+  })
+
   it('requires maxOutputBytes to fit the smallest counted outer payloads', async () => {
     const ctx = new Context()
     await expect(ctx.plugin(WorkerCodeRuntime, { maxOutputBytes: 3 })).rejects.toThrow(/safe integer of at least 4/)