Le composeur de menu consomme desormais GET /api/menus/{id} au lieu de composer
librement a partir des categories (dette P4 #3). Burger impose (burger_product_id),
un pas par slot reel (drink/side/sauce, options resolues), format Normal/Maxi au
prix du menu.
- data.js : loadMenu(id) (detail + slots) ; loadProductsById (index produit par id,
type 'produit' uniquement -> pas de collision avec les ids de menu).
- page-product-menu.js : reecrit slot-driven. Fonctions pures buildComposerSteps /
buildMenuCartItem / selectionsComplete / composerIsViable. composition produite
compatible avec page-cart.js et le panneau persistant L1 (slot_type -> champ).
- page-cart.js : rendu de composition tolerant aux champs absents ; libelle Maxi
("Format Maxi : +X") au lieu de "N grande(s)" devenu trompeur sous le forfait menu.
- tests : composer-slots.test.js + loadProductsById (data.test.js). 49/49 verts.
Revue adversariale (workflow, 14 findings / 12 confirmes) : must-fix integres --
SLOT_FIELD fait foi (slot_type hors drink/side/sauce ignore, l'enum DB autorise
dessert/extra -> plus de choix perdu) ; composerIsViable refuse d'ouvrir si burger
absent ou slot requis sans option (plus d'etape impassable) ; aria-hidden du fond
sous la modale ; role=dialog sur le conteneur ; overflow body sauvegarde/restaure.
Differes notes : multi-slots de meme type (menu famille), display_order vs maquette.
