Unexpected unique validation triggered when #unique: false is migrated from config

Problem/Motivation

When webform elements are migrated using Webform Migrate,
boolean properties such as #unique may be stored as false in configuration.
The current validation logic in WebformElementBase::validateUnique() checks for the
existence of the property using if (!isset($element['#unique'])).
This means #unique: false is treated as “set” and the validation runs, even though it should be disabled.

As a result, migrated elements that explicitly define #unique: false trigger the
“already submitted once” validation error:

The value Smith has already been submitted once for the Visitor’s Last Name element. You may have already submitted this webform, or you need to use a different value.

Although this could arguably be reported in Webform Migrate, the issue stems from Webform’s
own handling of the #unique flag. False values should be treated as such, ensuring
migrated configurations behave the same as freshly saved elements.

Steps to reproduce

1. Migrate a webform using Webform Migrate where a textfield element includes #unique: false.
2. Submit a form using the same value as a previous submission.
3. Observe that the “duplicate value” validation error appears unexpectedly.
4. Re-save the component in the UI and note that #unique: false is removed from configuration, resolving the issue.

Proposed resolution

Change the validation check to ensure the #unique flag is truthy before applying unique validation, e.g.:

if (empty($element['#unique'])) {
  return;
}

This prevents false boolean values from triggering the unique check and aligns with expected Webform behavior after saving in the UI.

Remaining tasks

• [ ] Adjust validateUnique() to check for truthy #unique.
• [ ] Add regression test to confirm no validation runs for #unique: false.