validateForm-based relay produces duplicate Monday rows on multi-step / preview-enabled webforms

Problem/Motivation

The current handler runs the Monday relay in validateForm() when
block_submit_on_failure is enabled. Webform fires the full validate
cycle on every form-action click — the preview button, wizard next/previous buttons, and
the draft button — not just the final submit. The result is that a webform with a preview
step (preview: 1) or multiple wizard pages calls create_item
once per click, producing two or more duplicate Monday rows per submission.

Steps to reproduce

1. Attach monday_crm_integration_create_item to a webform that has
   preview: 1 in settings (or has multiple wizard pages).
2. Leave block_submit_on_failure at its default true.
3. Submit the form: click the preview button, then the final submit button on the
   preview page.
4. Observe in Monday: two identical items created on the target board.
5. Observe in watchdog (channel monday_crm_integration): two log entries
   per submission.

Proposed resolution

Refactor the handler to use the canonical Webform pattern. Concretely:

• Remove validateForm() entirely.
• Move the relay to postSave(), gated on
  $webform_submission->getState() === STATE_COMPLETED. Mirror the
  results_disabled fallback that EmailWebformHandler::postSave()
  uses at line 884 so the relay still fires when the submission isn't persisted to the
  DB.
• Drop the block_submit_on_failure configuration key. The submission
  always saves; Monday delivery failures are surfaced to the submitter via
  $this->messenger()->addError() using the existing
  failure_error_message config, and logged with full diagnostics in
  relay() as before.
• Update the field-help for failure_error_message to reflect its new role
  (shown on failure regardless; leave empty to suppress).

This eliminates the duplicate-row bug by construction and aligns the handler with the
rest of the Webform ecosystem.

Remaining tasks

• Refactor MondayCreateItemWebformHandler — drop
  validateForm(), rewrite postSave().
• Update defaultConfiguration(), buildConfigurationForm(),
  submitConfigurationForm() to remove
  block_submit_on_failure.
• Add a kernel/functional test for the multi-step / preview-enabled case asserting
  exactly one Monday call per submission.
• Update README.md to document the new failure UX (submission always
  saves; failure_error_message shown to user, full diagnostics logged).
• Add a release note flagging the breaking change for sites currently relying on
  block_submit_on_failure: true

User interface changes

• The "Block the submission if Monday is unreachable" checkbox is removed from the
  handler configuration form.
• The "User-facing failure message" textarea remains, with updated help text
  describing the new behavior.

API changes

• Breaking: the block_submit_on_failure key is removed
  from the handler configuration. Existing webforms with this key set will need their config
  updated (key removed). Drupal config-import will tolerate the extra key, but the value is
  ignored.
• failure_error_message behavior changes: previously shown only when
  block_submit_on_failure: true and the relay failed during validation. Now
  shown via the messenger whenever the relay fails, regardless of any other config.

Data model changes

None.

Release notes snippet

Refactored MondayCreateItemWebformHandler to the canonical Webform handler
  pattern: relay now runs in postSave() gated on STATE_COMPLETED, matching
  EmailWebformHandler and RemotePostWebformHandler. This fixes a duplicate-row bug where
  preview-enabled or multi-page wizard forms produced two Monday items per submission,
  because Webform fires validateForm on every wizard/preview/draft button click. BREAKING
  CHANGE: the `block_submit_on_failure` config key is removed. Submissions always proceed to
   save; Monday delivery failures are surfaced to the user via the messenger using the
  existing `failure_error_message` config, and logged with full diagnostics on the
  `monday_crm_integration` channel.