Rescheduling a job via PATCH crashes if enabled is omitted

PATCH /v1/jobs/{id} is documented as supporting partial updates: enable/disable or reschedule, independently. A caller rescheduling a job -- the single most common PATCH use case, e.g. "change this job's cron expression" -- sends only {"cron_expr": "..."} and expects the job's enabled state to be left alone. Instead, every such request fails outright with a database constraint violation. This means the reschedule half of the documented PATCH functionality is completely broken for any caller that follows the API as documented, which is the normal, idiomatic way to call a PATCH endpoint.

internal/store/jobs.go's Patch builds its UPDATE with enabled = $2, cron_expr = COALESCE($3, cron_expr), run_at = COALESCE($4, run_at). cron_expr and run_at correctly use COALESCE to fall back to the existing value when the caller didn't provide one. enabled does not -- it's assigned directly. When PatchJobParams.Enabled is nil (the caller omitted "enabled"), $2 is NULL, and jobs.enabled is NOT NULL, so the whole update is rejected by Postgres.

curl -i -X PATCH localhost:8080/v1/jobs/1
-H 'Content-Type: application/json'
-d '{"cron_expr": "*/5 * * * *"}'

Observe: HTTP 500, with a Postgres "null value in column "enabled" ... violates not-null constraint" error in the logs.

COALESCE(new_value, existing_value) is the standard SQL idiom for "update this column only if a new value was actually provided" in a single UPDATE statement without dynamically building the SQL per-request. Three columns needed this treatment here; only two got it.

Compare the enabled line in the UPDATE to the cron_expr and run_at lines directly above and below it.