Offer "Add to cart" when a wishlist product's customization is optional

[boo-code]

Questions	Answers
Description?	The wishlist button branches on product.customizable, which is true for any product carrying customization fields. A product whose fields are all optional can be added to the cart directly - that is the rule the cart itself applies, through Product::hasAllRequiredCustomizableFields() in UpdateProductQuantityInCartHandler - so the wishlist offered "Customize" and sent the shopper to the product page for products that did not need it. The presenter already computes the distinction: ProductLazyArray exposes customization_required next to customizable, and ProductListingLazyArray extends it, so the flag is already in the payload this component receives. All seven uses in Product.vue move to it: the label, the button class, the cart icon, the click condition, the disabled rule and the add-to-cart guard.
Type?	bug fix
BC breaks?	no
Deprecations?	no
Fixed ticket?	Fixes PrestaShop/PrestaShop#37335
How to test?	Give a product a customization field that is not required, add it to a wishlist, and open the wishlist. The button reads "Add to cart" and adds the product, instead of reading "Customize" and navigating to the product page. A product with a required field is unchanged - it still reads "Customize", which is correct because the cart would refuse it.
Sponsor company

The built assets are deliberately not included

public/ is tracked in this repository and a _dev change normally ships with it rebuilt. I have left it out, because npm run build here does not reproduce the committed output: bundles my change cannot affect come back with 1 insertion and 19 deletions each, and public/productslist.bundle.js - the one that does carry the change - shows 4 insertions and 96 deletions, of which only 2 lines are the change itself. Committing that would bury a two-line behavioural fix under ninety-odd lines of formatting difference and risk shipping an asset built by the wrong toolchain. Regenerating public/ with the pinned toolchain is the last step and I would rather a maintainer did it, or tell me which Node version to match and I will.

Verification

The module's JS suite does not run on this machine - npm test fails with TypeError: a.a.emit is not a function inside mochapack, and it fails identically on the unmodified dev branch, so it is a toolchain incompatibility rather than anything this change introduced. There is no existing spec for Product.vue either. The change is therefore justified from core's own contract rather than from a test run: customization_required is computed at ProductLazyArray:169-191, listed among the exposed keys, and read by the cart handler that decides whether a direct add is allowed.

[Hlavtox]

@boo-code I would rather remove all of this Vue bullshit and render the product cards normally via a presenter and a tpl thats there in the core, like all other modules. This is just overengineered to extreme.

[boo-code]

The rewrite would not remove this bug on its own. customizable is true for any product carrying customization fields, while the cart admits a product through Product::hasAllRequiredCustomizableFields() - so a tpl branching on customizable reproduces exactly what Product.vue does today. The distinction is already in the payload either way: ProductListingLazyArray exposes customization_required next to customizable, so the card needs to read that one whether it is rendered by Vue or by a template.

This PR is that rename and nothing else - seven uses, no new Vue surface, no build output. If you would rather land the presenter and tpl version first, say so and I will close this and put the same distinction there instead.