TS SDK: generate Dag and task options from the serialization schema

[jason810496]

• next: TS SDK: name a task's inputs, and take its id from the handler #73437
• TS SDK: declare task dependencies by calling tasks #73435 is merged, so this is now the first of the stack; it applies to main on its own.
• Part of the native TypeScript Dag stack, TS SDK: declare task dependencies by calling tasks #73435 to TS SDK: cover native TypeScript Dags end to end #73446, to be merged in order.

Why

A native Dag has to express what Python would otherwise own: the schedule, and each task's options. Both already have a source of truth — Airflow's own Dag serialization schema — so the types are generated from it rather than hand-written, as src/generated/supervisor.ts is.

How

• ts-sdk/schema/dag-schema.json is a vendored copy of airflow-core/src/airflow/serialization/schema.json, kept honest by a prek hook, so a published npm package builds without the monorepo.
• scripts/generate-dag-schema.mjs emits GeneratedDagFields / GeneratedTaskFields plus the table the serializer reads. Task fields are derived; Dag fields come from a curated allowlist, because the dag definition mixes authoring options with bundle bookkeeping.
• Every eligible key of either definition has to be accounted for — a field, an exclusion, or a shape the spec cannot express. So a key the schema gains fails generation instead of going missing, and a key that changes shape fails instead of silently deleting its option and turning every call site that sets it into "Unknown option".
• TaskOptions.argBindings replaces argNames, matching the arg_bindings it fills in the serialized Dag and leaving withArgNames the only argNames in the SDK.

---

Was generative AI tooling used to co-author this PR?

• Yes, with help of Claude Code Opus 5 following the guidelines

[pierrejeambrun]

LGTM, just a couple of thing worth addressing.