Disabled scheduled workflow is re-enabled on app startup without a next run time

[Filed by Copilot on behalf of @bghgary]

### Affected version or release

v1.1.10 (`a7315e1`) and v1.1.11 (`0155271`)

### Installation context

Local Windows desktop app; one scheduled workflow created and disabled through the app's agent tool surface.

### What happened?

Disabling a scheduled workflow does not survive an app restart. Each launch changes its stored `enabled` value back to true but leaves `next_run_at` null. The UI therefore shows the workflow as enabled while it never becomes due.

This happened three times in 17 hours on one machine. The stored update followed the app process's first log line by 6 ms on v1.1.10 and 99 ms on v1.1.11:

| Stored update | Process start | Delta |
|---|---|---|
| `2026-08-19T23:09:11.411Z` | `23:09:11.405` v1.1.10 | +6 ms |
| `2026-08-20T19:03:19.124Z` | `19:03:19.025` v1.1.11 | +99 ms |

No renderer or CLI session had a transport when the first update occurred: it preceded the process listening on its WebSocket by 816 ms. While the app then remained running for about 20 hours, six workflow-list reads all returned `enabled: false` with an unchanged `updated_at`.

The v1.1.10 relaunch used the same version as the preceding process and logged no migration, so this was not introduced by the v1.1.11 schema migration. Only the disabled row's `updated_at` changed; enabled workflows preserved their timestamps across the same launches.

Enabling through `save_workflow` normally populates `next_run_at`; both restart flips left it null. The timing and stored state point to startup handling, but the app source is not public, so that path is inferred rather than code-confirmed.

### Steps to reproduce

1. Create a scheduled workflow with a cron expression.
2. Disable it through `save_workflow`.
3. Quit and relaunch the app.
4. Observe that it is enabled again but has no next run time.

### Expected behavior

The workflow remains disabled across app restarts.

### Additional context

- Windows 11 build 26310.
- The re-enabled workflow never ran. Each occurrence was caught within five minutes against a `*/30` cron, so none spanned a firing time.
- Every disable in this sample used `save_workflow`; disabling through the Workflows UI was not tested.
- Only one disabled workflow was observed across restart.
- https://github.com/github/app/issues/1158 is related, but it covers manual/removed workflows remaining visible and the missing delete path rather than this disabled-to-enabled state change.

The issue names no files, tests, or public entry points, and says the app source is not public. Start by reproducing the save_workflow, quit, and relaunch sequence on Windows while inspecting the stored workflow state. Done means a disabled scheduled workflow remains disabled after restart and does not acquire a next run time.

Written by the indexing model from the issue text.