fix(cli): skip setScheduleEnabled when local YAML lacks enabled

Tarball export from a fork strips `enabled` from schedules so the
fork→parent git-sync round-trip can't flip the parent's operational
state. The CLI's pushSchedule called setScheduleEnabled whenever
`localSchedule.enabled != schedule.enabled`, which evaluates truthy
when local is undefined (fork-pulled YAML) and remote is true/false —
sending `{ enabled: undefined }` that serializes to `{}` and gets
rejected by the backend (`SetEnabled.enabled` is required).

Skip the call when `localSchedule.enabled === undefined` so a sync push
of fork-pulled YAMLs preserves the target's existing enabled state
instead of erroring out. Trigger updates were already safe — the
backend's update_trigger preserves `mode` when the request omits it.

cli/src/commands/schedule/schedule.ts

@@ -153,7 +153,15 @@ export async function pushSchedule(
           ...preserveFields,
         },
       });
-      if (localSchedule.enabled != schedule.enabled) {
+      // Only push `enabled` when the local YAML actually carries it. Tarball
+      // export from a workspace fork strips the field (so fork→parent
+      // round-trips don't flip the parent's operational state), which means
+      // a sync push of fork-pulled YAMLs would otherwise call setEnabled
+      // with `enabled: undefined` and the backend would reject the body.
+      if (
+        localSchedule.enabled !== undefined &&
+        localSchedule.enabled !== schedule.enabled
+      ) {
         log.info(colors.bold.yellow(
           `Schedule ${path} is ${localSchedule.enabled ? "enabled" : "disabled"} locally but not on remote, updating remote`
         ));