Guard identifier key access and declare callerPage property in ApplePay

[mmaymo]

What and why

During the Apple Pay checkout flow, two PHP notices were being written to the error log on every request: a PHP Warning for an undefined array key identifier in ResponsesToApple::reorderShippingMethods, and a PHP Deprecated notice for dynamic property creation of $callerPage on ApplePayDataObjectHttp. Neither notice
blocked checkout or affected the user experience, but both polluted error logs and represent
forward-compatibility risks — dynamic property creation is deprecated in PHP 8.2 and will become a fatal error
in a future PHP version, while undefined array key access is already an E_WARNING that strict error
configurations can surface as an exception.

How it works now

In ResponsesToApple::reorderShippingMethods, the direct comparison $method['identifier'] === $selectedShippingMethod['identifier'] has been replaced with ($method['identifier'] ?? null) === ($selectedShippingMethod['identifier'] ?? null), so a missing identifier key on either side returns null
instead of raising a warning. In ApplePayDataObjectHttp, $callerPage is now declared as an explicit
protected class property with a @var string|null docblock, which means assignDataObjectValues no longer
creates it as a dynamic property when it assigns values from POST data.

What to verify in review

Covered by unit tests

• ✓ The identifier key access in ResponsesToApple::reorderShippingMethods is guarded with ?? so a missing
  key does not raise a PHP Warning
• ✓ The $callerPage property is explicitly declared in the ApplePayDataObjectHttp class body and is no
  longer assigned dynamically

Not covered by unit tests

• ✗ No PHP Deprecated notice for $callerPage is logged — structurally guaranteed once the property is
  creates it as a dynamic property when it assigns values from POST data.

[danielhuesken]

LGTM