Guard id lookups against built-in object properties

We use plain objects as lookup tables keyed by step and workflow ids, and a few names are already properties of every JavaScript object, so a lookup returns a built-in instead of nothing.

Three things follow, all reproduced. A step named constructor is reported to Lightning as failed when it succeeded, because calculateJobExitReason in packages/ws-worker/src/api/reasons.ts reads state.errors[jobId] and gets the Object function. A step named __proto__ is dropped from the plan in compile-plan.ts and never runs, silently. An adaptor named constructor crashes autoinstall with a type error rather than failing cleanly.

Step ids arrive from Lightning unchecked, so none of this needs a hand-edited file.

The first one is worth a note because it fooled me twice. state.errors is built with Object.create(null), so it reads as safe. But it crosses process.send on the way out of the worker pool, and that trip serialises it to JSON and hands back an ordinary object with the built-ins restored. A comment claiming it is safe by construction is only true on one side of that boundary.

Fixing these one site at a time has not gone well elsewhere, so it is probably worth deciding how to stop it recurring rather than only where it is now.

Came up while investigating lightning#4577, though none of it is about Unicode.

Start with calculateJobExitReason in packages/ws-worker/src/api/reasons.ts, then inspect compile-plan.ts and the autoinstall path. Trace how state.errors crosses process.send and is serialized, and reproduce the constructor and proto cases. Done means step and adaptor ids cannot resolve to built-in object properties and invalid lookups fail cleanly across all three sites.