`--retries` has no default, so the CLI cannot run without it

[taras]

Every invocation that does not pass --retries fails, including the one this project's own deploy workflow has always used.

staticalize-linux --site=http://127.0.0.1:8000 --output=www/built --base=https://frontside.com/effection
→ retries: Invalid input: expected number, received undefined

The v0.2.6 binary accepts that exact command and crawls; v0.3.0 rejects it, so this is a regression, and it blocks upgrading to 0.3.0 without editing every caller.

Cause

In config.ts, concurrency gets a default and retries does not:

concurrency: {
  description: "Maximum number of concurrent downloads. …",
  ...field(z.number(), field.default(75)),
},
retries: {
  description: "Number of times to retry a failed download before giving up. Defaults to 0 in strict mode.",
  ...field(z.number()),
},

--help advertises a default that the schema never supplies, so the flag is documented as optional and required in practice.

Repro

With stdin closed, which is how CI runs it, the behaviour is consistent across runs:

invocation	result
--site … --output … --base …	retries: Invalid input: expected number, received undefined
… --retries=3	crawls
… --concurrency=75 --retries=3	crawls

(v0.3.0 release binary, macos-arm64, against a three page test site.)

Also noticed

Running the same invocations in a shell loop without redirecting stdin gave inconsistent results — the same arguments sometimes crawled, sometimes failed with received undefined, and sometimes with received string. Redirecting < /dev/null made it deterministic every time. I did not chase it down, but the CLI does read stdin (initStdin in main.ts), so it may be consuming it when nothing was piped. Worth knowing, because it makes casual testing of this bug look flaky.

Workaround

thefrontside/effection#1248 passes --concurrency=75 --retries=3 so it can adopt 0.3.0 for the text rewriting in #13. Those flags come out once the default is restored.