actions.check: validate nested shapes with the executor's own validator

[Michaelliv]

actions.check looped only over an action's top-level inputs, comparing each immediate type/enum/const. A payload whose defect lived one level down — an array item missing its required field, or carrying a forbidden one — came back ok: true, and the documented check-before-write workflow walked the agent straight into a rejected call. The flattened help metadata could never close the gap: it truncates deep nesting and carries no additional-properties rules.

Now the raw typed schema travels into the worker alongside the help data, and check runs the same typebox Check/Errors the host runs before execute — the preflight verdict and the execution verdict come from one validator on one schema and cannot diverge. TypeBox schemas are plain JSON, so they survive the stringify into the worker source; typebox/value is resolved host-side and required by absolute path, exactly like ferrosearch (bun and node ≥22.12).

The familiar missing/unknown/typeErrors buckets are derived from the validator's structured errors (keyword + params, never message parsing) with nested paths spelled members[0].externalId, grouping a failed union into one typeError instead of one per branch. A new errors array carries each raw <path> <message> line exactly as a rejected execution would report it; legacy flat schemas keep the existing field loop and gain the empty array for a uniform shape.

Two deliberate parity-driven semantics changes: stray keys under permissive additionalProperties now pass check (execute accepts them), and check(path, null) fails like execution instead of coercing to {}.

Five new tests, four seen red against the flat loop — including a parity test proving every check error line appears verbatim in the execution rejection for the same payload. Full suite 474 pass.