Lower fallback grace default from 30s to 3s

ckpool patch 0004 now bounds generator_submitblock's wait for a live
primary to ~3s rather than spinning indefinitely, and calls submit
before writing the pending-block hex to disk so the happy path adds
zero latency. The right default is small: a fallback should kick in
while the work is still relevant for the current chain tip.

Range widened to [1, 600] so impatient operators can crank further
down. Description updated to reflect the new architecture.

scripts/procedures/getConfig.ts

@@ -230,12 +230,12 @@ export const getConfig: T.ExpectedExports.getConfig = compat.getConfig({
             "type": "number",
             "name": "Grace period (seconds)",
             "description":
-              "How long a block waits before kamado-api considers ckpool's submission attempt failed and broadcasts via fallback. 30s gives ckpool's own retry loop room to succeed against the primary.",
+              "How long a block waits before kamado-api considers ckpool's submission attempt failed and broadcasts via fallback. The patched ckpool returns from submit within ~3s rather than spinning indefinitely on a dead primary, so 3s is the right default — fast enough that fallback work happens while the block is still novel, long enough that a slow round-trip on a healthy primary doesn't trigger a spurious fallback.",
             "nullable": false,
-            "range": "[10,600]",
+            "range": "[1,600]",
             "integral": true,
             "units": "seconds",
-            "default": 30,
+            "default": 3,
           },
           "backup-rpcs": {
             "type": "list",