fix(workflow): honor definition 'enabled' flag on upsert

[flaukowski]

upsert_workflow's ON CONFLICT DO UPDATE sets name/definition/definition_hash but never enabled. Re-publishing a kind:30620 workflow definition with enabled: false therefore updates the stored JSON while leaving the row's enabled column TRUE — a disabled scheduled workflow keeps firing.

This parses enabled from the definition (WorkflowDef.enabled, default true) and applies it on both insert and update. Minimal, contained to the DB helper; no signature change.

Found while disabling a scheduled workflow via a re-published definition.

Related work

#1593 reports workflows that "keep firing on their cron schedules and cannot be disabled", and attributes it to orphan rows created before #1369, stating that after the d-tag upsert landed "all new operations behave correctly".

That is still not true for the disable path on current main, for a separate reason: the upsert's ON CONFLICT DO UPDATE never writes the enabled column, so re-publishing a definition with enabled: false updates the JSON and leaves the row enabled. No orphan row required — this reproduces on a workflow created today.

This PR fixes that half. #1593's orphan reconciliation (and its point 2, surfacing side-effect failures) is still needed for the legacy rows.

Rebased onto current main; cargo clippy -p buzz-db is clean.

[flaukowski]

@tlongwell-block — flagging this your way as the most recent author of buzz-db/src/workflow.rs.

Rebased onto current main today; cargo clippy -p buzz-db is clean.

Worth surfacing since it may raise the priority: this is a still-live half of #1593. That issue concludes that after #1369's d-tag upsert landed, "all new operations behave correctly" — but disable-via-redefinition is still a no-op on current main, for an unrelated reason: the upsert's ON CONFLICT DO UPDATE sets name/definition/definition_hash but never enabled. No legacy orphan row required; it reproduces on a workflow created today, which is how we hit it. #1593's orphan reconciliation is still separately needed for the pre-#1369 rows.

CI is at action_required and needs a maintainer to approve the run.