Thanks for the PR, @bergeouss! Duplicate cron job with form pre-fill is a quality-of-life feature that makes it much faster to set up similar recurring jobs. Pre-filling the create form and defaulting the clone to paused is the right UX — the user reviews and enables deliberately rather than accidentally running a duplicate.

A few things to confirm before merge:

1. Name collision handling: The PR appends '(copy)' to the name. If the user duplicates the same job multiple times, they'd get "Job name (copy)", "Job name (copy) (copy)", etc. Is there any deduplication logic, or is that acceptable?

2. Schedule field behavior: The PR says duplicated jobs have "schedule cleared." Is the schedule field shown empty in the create form, or is there a placeholder/hint showing the source job's schedule so the user can easily re-enter a modified version?

3. Pre-fill source: duplicateCurrentCron() extracts settings from the current detail view. Is the extraction from the in-memory state or from a fresh API call? If the job was edited but not saved, would the duplicate use the unsaved edits or the persisted values?

4. ID/schedule/enabled clearing: The PR notes these three fields are cleared. Confirming enabled: false is explicitly set (not just cleared to falsy) so the created job is always saved as paused regardless of the source job state.

The change is lean (3 files, 41 additions). Once the above are confirmed this looks solid!

Thanks for the thorough review! Updated the PR to address points 1 and 4:

1. Name collision → Fixed. The duplicate now checks _cronList for existing names and auto-increments: Job (copy), Job (copy 2), Job (copy 3), etc.

2. Schedule field → The schedule is actually pre-filled (not cleared). It uses job.schedule_display || job.schedule.expression, so the user sees the original schedule and can modify it. The placeholder hint "0 9 * * * — every 1h — @daily" is also shown. ✅

3. Data source → Extracted from _currentCronDetail, which is the persisted job object loaded via API when the detail view opens. Since edits go through the editCurrentCron() → openCronEdit() → saveCronForm() flow (which replaces the detail view with the edit form), the duplicate button is only visible in read mode, so it always uses persisted values. ✅

4. enabled: false → Fixed. Added _cronIsDuplicate flag that is set to true only in duplicateCurrentCron(). When saving, if the flag is set, enabled: false is explicitly sent in the create request body. Normal cron creation (via the + button) is unaffected — no enabled field is sent, so the backend default applies.

Thanks for following up, @bergeouss! All four points are addressed:

• (1) Name collision: The auto-increment logic (Job (copy) → Job (copy 2) → Job (copy 3)) checking against _cronList is the right UX — no stacking (copy)(copy) chains.
• (2) Schedule pre-fill: Good to hear the schedule is pre-filled rather than cleared — that's more useful for the "similar job" use case, and having the placeholder hint visible covers the editing guidance.
• (3) Data source: The duplicate button only being available in read mode (not edit mode) is a clean invariant — always uses persisted values, no ambiguity.
• (4) enabled: false: The _cronIsDuplicate flag approach is clean — explicit enabled: false in the create request when duplicating, no change to the normal create path's default behavior.

All four points are solid. This looks ready for maintainer merge review.

Merged in v0.50.237 via #1243. Thank you @bergeouss! 🎉