fix: adapt changes in create mode for edit mode, cleanup

src/Form/Service/Condition/AuthenticatedUserPersonalDataCondition.php

@@ -10,7 +10,7 @@ use App\Form\Service\Contract\FieldConditionInterface;
 /**
  * Condition that determines if personal data fields should be hidden for authenticated users.
  *
- * When a participant is linked to an existing BPN account (has addressId and personId),
+ * When a participant is linked to an existing BPN account (has personId),
  * their personal data should not be editable during the booking process. Changes to
  * master personal data should only happen through the dedicated personal data management
  * interface to prevent:
@@ -18,6 +18,10 @@ use App\Form\Service\Contract\FieldConditionInterface;
  * - Disconnecting bookings from the user's account
  * - Data inconsistencies between booking and account data
  *
+ * Note: In edit mode, the BPN API may not return addressId in booking responses,
+ * so we rely on personId alone to identify authenticated users. The personId is
+ * sufficient to link a participant to an existing BPN account.
+ *
  * When this condition is satisfied (returns true), the template should:
  * - Hide the form fields for personal data
  * - Display the values as static, read-only text
@@ -46,9 +50,10 @@ class AuthenticatedUserPersonalDataCondition implements FieldConditionInterface
             return false;
         }
 
-        // Hide personal data fields if participant has BPN account IDs
-        // (indicates prepopulation from authenticated user)
-        return null !== $participant->addressId && null !== $participant->personId;
+        // Hide personal data fields if participant has BPN person ID
+        // In edit mode, bookings may not include addressId, so we check personId only
+        // The personId alone is sufficient to identify a participant linked to a BPN account
+        return null !== $participant->personId;
     }
 
     /**