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/README.i18n.yaml

@@ -1,6 +1,6 @@
 # Bilingual-pair consistency record (docs/i18n/README.md): the git blob hash of each
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
-#   pnpm run verify-translation-pairing --write
-README.md: acc0e37e73d3887c70a77d16311305e52f5a4030
-README.zh.md: 15983dba00eff6fbc6e6d32a4d22df3a4249af76
+#   pnpm run verify-translation-pairing --write packages/code-runtime/code-runtime-worker/README.md
+README.md: 90f6f1bce07c2a0e83b411b6d85e9cd1cd4a5f31
+README.zh.md: 56aa99a1160a19025c7cb09314ddb7b9aec56890