Send the back in stock alert to the address it was registered with

[boo-code]

Questions	Answers
Description?	An alert row in ps_mailalert_customer_oos stores both id_customer and customer_email, but MailAlert::sendCustomerAlert() always took the recipient from the customer record. Once that customer is deleted the id no longer resolves, Customer::__construct() hands back an unloaded object, the recipient is empty and Mail::Send() reports Error: parameter "to" is corrupted - fatally when the shop is in debug mode, which aborts the stock update. The stored address is used when the customer record no longer resolves, and a row with no usable address at all is skipped so one bad row cannot break the alerts for every other customer waiting on that product.
Type?	bug fix
BC breaks?	no
Deprecations?	no
Fixed ticket?	Fixes PrestaShop/PrestaShop#27489
How to test?	Register for a back-in-stock alert on an out-of-stock product as a logged-in customer, then delete that customer in the back office - the row in ps_mailalert_customer_oos survives with the now dangling id_customer. Put the shop in debug mode and set the product's quantity above zero. Before: the save dies with Error: parameter "to" is corrupted. After: the alert is sent to the address stored on the row and the stock update completes. Alerts for existing customers are unchanged.

The module template has no Branch? / Category? / UI Tests rows - copy the live
.github/PULL_REQUEST_TEMPLATE.md from ps_emailalerts verbatim at publish time.

Measured RED -> GREEN through the real caller

Seeded ps_mailalert_customer_oos(id_customer = 999999, customer_email = 'probe27489@example.test') for an
active product, then called MailAlert::sendCustomerAlert($idProduct, 0):

module as shipped   -> Error: parameter "to" is corrupted        (died, exactly the reported message)
module patched      -> completed without dying

Supporting measurement: new Customer(999999) gives id=NULL, email=NULL, so (string) $c->email is ''
and Mail::Send() hits if (!is_array($to) && !Validate::isEmail($to)) at classes/Mail.php:261.
Recipient resolution after the fix returns the stored probe27489@example.test; a row with an empty
customer_email yields Validate::isEmail('') === false and is skipped.

Verified against upstream, not just the installed copy

The installed module is 3.0.1; the fix targets PrestaShop/ps_emailalerts@dev, whose MailAlert.php carries
the identical block (the only difference between the two files is an unrelated id_product_attribute line).

Gates

• php -l clean; php-cs-fixer (module's own .php-cs-fixer.dist.php) Found 0 of 1 files that can be fixed.
• The module ships no PHPUnit suite - tests/ contains only PHPStan configs - so there is no unit test
  to add; the deterministic repro above stands in, per the same convention used for blockwishlist.
• PHPStan was not run: the module's phpstan.neon lists MailAlert.php under scanFiles, not paths,
  so it is never analysed there anyway.

Not done

maildev is not running in this environment, so delivery of the alert was not observed end to end - only
that the resolved recipient is a valid address and that the call no longer dies.