fix: strip API-only settings before workflow create/update

[avi90210]

Summary

• Strip availableInMCP, binaryMode, and callerPolicy from workflow settings before sending create/update API requests
• These properties are exported by the n8n API on GET but rejected on PUT/PATCH with request/body/settings must NOT have additional properties
• Follows the existing pattern where pinData is already excluded from the request body

Problem

When using n8n-cli import followed by n8n-cli apply, the imported YAML contains server-side settings that the API rejects on write. This forces users to manually strip these fields before pushing.

Fix

Added a sanitizeSettings() method in executor.ts that blacklists known API-only settings, applied in both executeCreate() and executeUpdate().

Test plan

• Imported workflows with availableInMCP, binaryMode, callerPolicy in settings
• Verified apply succeeds without manual field stripping
• Verified apply --dry-run shows no errors

---

Note

Low Risk
Low risk, narrowly filters out three known settings keys before write requests to avoid n8n API validation errors; primary risk is unintentionally dropping a setting if the blacklist is incomplete/incorrect.

Overview
Prevents apply create/update requests from failing due to n8n returning API-only workflow settings fields on read.

Adds sanitizeSettings() in Executor to remove availableInMCP, binaryMode, and callerPolicy, and uses it when building the WorkflowInput for both executeCreate() and executeUpdate().

^{Reviewed by Cursor Bugbot for commit 3937e3c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[syucream]

@avi90210 fix the DCO check please