Redirect skipped if a response has been set on the form state

I was hoping someone would eventually come along and say "yeah this fixes a big conflict with other contrib modules and definitely doesn't break anything else" but that never happened. The fact that the steps to reproduce require setting up a module I've never used before didn't help, so I never got around to this.

I used an AI assistant to evaluate the MR and here's what it came up with:

Root cause confirmed against Drupal core, not just the reported symptom. Core's FormSubmitter::doSubmitForm() checks getResponse() before ever calling redirectForm():

// If no response has been set, process the form redirect.
if (!$form_state->getResponse() && $redirect = $this->redirectForm($form_state)) {

save_edit_form_submit_redirect() only calls setRedirectUrl(), which sets a separate property (FormState::$redirect) that getResponse() never sees. Once Domain Source calls setResponse(), save_edit's redirect is discarded regardless of submit handler order. Switching to setResponse() directly, as the MR does, is the right general direction.

Two changes needed before this is safe to merge:

1. The MR drops the redirect guards that setRedirectUrl() got for free through FormState::getRedirect() — that method returns FALSE (suppressing the redirect) when the form is programmatically submitted, rebuilding, or has redirects explicitly disabled. setResponse() has no such guard; it's a bare setter. As written, the patch will force a redirect during an AJAX-triggered rebuild or a programmatic submitForm() call sharing this submit chain. It should check isProgrammed() / isRebuilding() / isRedirectDisabled() and bail out early, the same way core does before it would otherwise call setRedirectUrl().

2. TrustedRedirectResponse isn't needed — the target is always the entity's own edit-form route, never external. Core's own redirectForm() uses plain RedirectResponse for this same case; matching that keeps the patch consistent with core instead of implying it needs the "trusted external redirect" escape hatch.

One non-blocking observation: the fix works because save_edit's submit handler happens to run after Domain Source's when the button is cloned in save_edit_form_alter() (Domain Source's hook_form_alter() runs first under default module weights, so its handler is already present on the array save_edit copies, and save_edit's own handler is appended last). That ordering is incidental, not enforced — a third module altering the same button with a later effective position could reproduce this exact bug against save_edit itself. Not a reason to hold up this fix, but worth a code comment noting the assumption.

Hi, I'd like to avoid performing any "linting" on 2.x given that Drupal 10 is EOL soon and I'd like to cut over to a 3.0.0 release not long into the new year. Feel free to add tests but please do not do any 2.x linting since it clutters commits with unrelated changes. Also, if possible, ensure that *identical* bug fixes and tests are provided for both 2.x and 3.x (or at least, functionally identical bugfix code on 3.x)

Linting and code cleanup will be handled separately at #3619151 for 3.x only.