fix(webapp): treat a zero debounce ceiling as no ceiling rather than a boot failure

Zero was previously a legal value meaning the window closes on the first
push, so rejecting it would stop an existing deployment from starting
after an upgrade. Accepting it as a real ceiling is worse still, since
the trigger-time check would then reject every debounced trigger. Zero
and blank now both mean no ceiling, which keeps the setting switchable
off and leaves negatives and garbage rejected.

Also note in the docs that a trigger omitting maxDelay now has no bound
at all, where it previously fell back to the built-in ceiling.

Author: matt-aitken

apps/webapp/app/env.server.ts

@@ -114,11 +114,17 @@ const OptionalIntEnv = z.preprocess(
   z.coerce.number().int().optional()
 );
 
-/** As {@link OptionalIntEnv}, but a value that is set must be greater than zero. */
-const OptionalPositiveIntEnv = z.preprocess(
-  (v) => (typeof v === "string" && v.trim() === "" ? undefined : v),
-  z.coerce.number().int().positive().optional()
-);
+/**
+ * Optional int env var for a limit that can be switched off. Blank, whitespace and `0` all mean
+ * "no limit" and normalise to undefined; anything else that is set must be greater than zero.
+ */
+const OptionalLimitEnv = z.preprocess((v) => {
+  if (typeof v === "string" && (v.trim() === "" || Number(v.trim()) === 0)) {
+    return undefined;
+  }
+
+  return v === 0 ? undefined : v;
+}, z.coerce.number().int().positive().optional());
 
 const EnvironmentSchema = z
   .object({
@@ -1047,9 +1053,9 @@ const EnvironmentSchema = z
      * bound. Setting this applies a ceiling to every debounced run that does not carry its own
      * `maxDelay`, and any `delay` at or above it is rejected at trigger time. It is a default
      * rather than an enforced limit: a trigger that sets `maxDelay` uses that value even when it
-     * is longer than this.
+     * is longer than this. `0` and blank both mean no ceiling.
      */
-    RUN_ENGINE_MAXIMUM_DEBOUNCE_DURATION_MS: OptionalPositiveIntEnv,
+    RUN_ENGINE_MAXIMUM_DEBOUNCE_DURATION_MS: OptionalLimitEnv,
 
     /**
      * Bucket size in milliseconds used to quantize the newly computed `delayUntil`

docs/triggering.mdx

@@ -933,8 +933,9 @@ Keep `delay` well below `maxDelay`. A run is only pushed back while its new exec
 <Note>
   The `maxDelay` value is evaluated from each trigger call, not stored with the original run. This
   means if you pass different `maxDelay` values for the same debounce key, each trigger uses its own
-  `maxDelay` to check against the original run's creation time. For consistent behavior, use the
-  same `maxDelay` value for all triggers with the same debounce key.
+  `maxDelay` to check against the original run's creation time. A trigger that omits `maxDelay`
+  has no bound at all, so a single call without it can push the run past the limit the other calls
+  set. Use the same `maxDelay` value for every trigger with the same debounce key.
 </Note>
 
 **Leading vs Trailing mode:**