fix(workflows): omit undefined step config keys from bridge

[LordCoughmann]

Problem

A Cloudflare.Workflows.task step that declares retries but no timeout crashes on the first attempt with:

TypeError: Cannot read properties of undefined (reading 'match')

Root cause

WorkflowBridge.toWorkflowStepConfig reconstructs the config object before handing it to the native step.do:

return { retries: options.retries, timeout: options.timeout };

When only retries is set, this produces { retries: {...}, timeout: undefined } — an explicitly present undefined key.

The local engine then merges step config over its defaults with a shallow spread:

let config: ResolvedStepConfig = { ...defaultConfig, ...stepConfig, retries: {...} };

so the explicit timeout: undefined overwrites defaultConfig.timeout ("10 minutes"). The step's timeout watchdog subsequently calls ms(config.timeout), and ms(undefined) throws the reading 'match' error inside itty-time.

Native cloudflare:workers callers never emit timeout: undefined (the key is simply absent), so this is specific to the Alchemy bridge.

Fix

Omit keys that are undefined in toWorkflowStepConfig, so a retries-only step keeps the engine timeout default:

const config: WorkflowStepConfig = {};
if (options.retries) config.retries = options.retries;
if (options.timeout !== undefined) config.timeout = options.timeout;
return Object.keys(config).length > 0 ? config : undefined;

Test

Adds a regression test in WorkflowBridge.test.ts asserting the bridge passes { retries } with no timeout key.

Notes

• I could not run alchemy-test locally (existing test files fail with describe/test/hook called outside of a test file collection in my environment), so CI verification is appreciated.
• Optional hardening (separate concern, not included): the engine's default-merge could defensively skip undefined values, which would make the engine resilient regardless of what the bridge passes.

[sam-goodwin]

I ran the tests, they pass