Multiple "Trying to access array offset on null" warnings in Inline Entity Form

Claude Code says:

● Review: 3560018-warning-trying-to vs 3.x

Two commits, both small defensive patches for PHP 8 warnings.

cd723b2 — InlineEntityFormComplex::extractFormValues()

src/Plugin/Field/FieldWidget/InlineEntityFormComplex.php:731-735

  $element = NestedArray::getValue($form, [$field_name, 'widget', 'form']);
  if ($element && isset($element['inline_entity_form']['#entity'])) {
    $entity = $element['inline_entity_form']['#entity'];
    $values[] = ['entity' => $entity];
  }

Guards against NestedArray::getValue() returning NULL before the ['inline_entity_form']['#entity'] dereference. Correct fix for the literal warning.

Concerns:
- Papers over a state mismatch. The branch is only entered when $widget_state['form'] == 'add'. If widget state says "add" but there's no form at [$field_name, 'widget', 'form'], something upstream is out of sync — likely a form rebuild, #access = FALSE, or a form_alter stripping it. Worth understanding why before silently no-oping.
- Potential silent data loss. The whole point of this empty($values) && !empty($widget_state['form']) block is to preserve the in-progress "add" entity across rebuilds. Skipping the append means that entity disappears from $values. If the trigger condition does occur with a real user-built entity, this fix hides a bug where the user's work vanishes. Consider at least logging, or confirming in the issue that this only fires on no-op rebuilds.
- No test.

b1d4e38 — inline_entity_form_open_form()

inline_entity_form.module:220-223

  $parents = $element['#field_parents'] ?? [];
  if (!empty($element['#field_name'])) {
    $parents[] = $element['#field_name'];
  }

Same flavor — guards the array_merge when either key is missing on the element returned by inline_entity_form_get_element().

Concerns:
- Those keys are normally stamped onto the widget element by core's WidgetBase::form(), and the + $element merge at InlineEntityFormComplex.php:297 preserves them. Missing keys suggest either a nested-IEF case where #ief_root resolves to an inner widget that didn't inherit them, or a form-alter that dropped them. The commit message doesn't name the reproducer.
- Silent downstream misbehavior. When #field_name is missing, $parents ends up pointing at the wrong subtree (or the whole getUserInput() when both keys are missing). The subsequent $form_values['actions']['bundle'] lookup will miss, so the bundle-selector path on line 228 quietly stops working. The warning is gone, but the feature is broken in exactly the case the guard protects against.
- No test.

Overall

Both patches are low-risk and fix real PHP 8 warnings users are hitting — fine to land in isolation. But both convert loud errors into silent wrong-behavior without diagnosing why the inputs are malformed in the first place.

Suggestions before merge:
1. Get a reproducer from the d.o issues (nested paragraphs? a specific form-alter? a custom widget wrapper?). The fix may be upstream of these spots.
2. Add a short in-code comment on each guard noting when/why the keys can be absent — saves a future maintainer the spelunking.
3. Add at least one regression test per fix in tests/src/FunctionalJavascript/.
4. Consider whether cd723b2's silent skip is actually user-safe, or whether in the real repro scenario it loses an in-progress entity.

Upon second look, this code is fine as is and won't hurt a thing. Sorry for the BS AI review in #6.