fix: include webhook_reply and cron_cursor_job_id in version hash

[officialasishkumar]

Description

This PR fixes the version hash calculation to include webhook_reply and cron_cursor_job_id trigger fields. Previously, WorkflowVersions.generate_hash/1 only hashed :type, :cron_expression, and :enabled from triggers, meaning changes to webhook reply mode or cron cursor job were invisible to CLI deploy and sandbox merge.

Closes #4596

Additional notes for the reviewer

1. The fix adds two atoms to the trigger_keys list in generate_hash/1. No structural changes to the hash algorithm.
2. PR feat: export webhook_reply and cron_cursor_job in provisioner #4597 already handled the export/import side; this completes the story by ensuring the version hash also tracks these fields.

AI Usage

• I have used Claude Code
• I have used another model
• I have not used AI

Used only for research.

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review
  with Claude Code)
• I have implemented and tested all related authorization policies.
  (e.g., :owner, :admin, :editor, :viewer)
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR

[Copilot]

Pull request overview

This PR fixes workflow version hash generation so that trigger changes to webhook_reply and cron_cursor_job_id are reflected in the hash, ensuring CLI deploy and sandbox merge correctly detect those changes (per #4596).

Changes:

• Extend WorkflowVersions.generate_hash/1 trigger hashing to include :webhook_reply and :cron_cursor_job_id.
• Add regression tests asserting the hash changes when either of those trigger fields changes.
• Document the fix in the changelog under Unreleased / Fixed.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
lib/lightning/workflow_versions.ex	Adds webhook_reply and cron_cursor_job_id to the trigger field list used for deterministic hashing.
test/lightning/workflow_versions_test.exs	Adds tests verifying hash changes when webhook_reply or cron_cursor_job_id changes.
CHANGELOG.md	Notes the hashing fix in the Unreleased “Fixed” section with issue link.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[elias-ba]

Hey @officialasishkumar, thanks so much for this contribution, really appreciate you picking this up!

The change itself makes sense. One thing to consider though: the CLI computes version hashes using the same algorithm, and its trigger keys need to stay in sync with the server.

In kit/packages/project/src/util/version.ts (line 57), the CLI currently has:

const triggerKeys = ['type', 'cron_expression', 'enabled'].sort();

This needs to be updated to:

const triggerKeys = ['type', 'cron_expression', 'enabled', 'webhook_reply', 'cron_cursor_job_id'].sort();

Without this, the CLI and server will produce different hashes for the same workflow, and deploy will think workflows changed when they haven't.

Would you mind opening a companion PR in the kit repo with that update?

cc @josephjclark

[elias-ba]

There's a small merge conflict in CHANGELOG.md, just needs a rebase onto main and moving the entry under the current ## [Unreleased] / ### Fixed section.

[officialasishkumar]

@elias-ba Rebased onto current main, resolved the CHANGELOG.md conflict under the current ## [Unreleased] / ### Fixed section, and opened the companion kit PR here: OpenFn/kit#1362

[officialasishkumar]

Opened the companion change in OpenFn/kit as #1362. This branch is also current on main, and the changelog entry is already under Unreleased / Fixed.

[josephjclark]

Hi @officialasishkumar, your AI disclaimer says you haven't used AI to produce this PR (including research, comments and the PR description). Is that true?

[officialasishkumar]

@josephjclark Yes, used only for research.

[elias-ba]

@officialasishkumar Thanks for being upfront about it, we really appreciate that. To be clear, we actively encourage contributors to use AI tools. We all rely on them to deliver faster and better work, and there's absolutely no stigma attached.

That said, transparency is important to us. Whether AI was used for research, fact-checking, writing docs, drafting code, or anything else, it all counts as AI usage. The "I have not used AI" checkbox should only be ticked if you genuinely didn't use any form of AI assistance at all during your work on this PR.

Would you mind updating the checkboxes to reflect your actual usage? Either "I have used Claude Code" or "I have used another model" would be appropriate here. Once you've done that, please re-request a review and I'll approve this right away.

[officialasishkumar]

Updated @elias-ba