Demande de sponsoring : rendre le mail générique

[BySplashGm]

Demande de sponsoring : rendre le mail générique

Closes #2189

Contexte

Le dossier de sponsoring couvre plusieurs évènements (AFUP Day, toutes villes confondues, + Forum PHP),
mais le mail envoyé au prospect n'en nommait qu'un seul : celui de la page
depuis laquelle le formulaire a été rempli.

Depuis /become-sponsor, BecomeSponsorLatestAction redirige vers l'évènement retourné
par EventRepository::getCurrentEvent() (le prochain par date, ORDER BY date_debut LIMIT 1) :
c'est bien le « premier trouvé » signalé dans l'issue. Ce titre d'évènement était ensuite
interpolé (%eventName%) dans le sujet et le corps du mail, d'où l'effet déroutant
(« Dossier de sponsoring AFUP Day 2026 … » pour un dossier qui parle aussi du Forum).

Modifications

• Mail au prospect rendu générique : suppression de %eventName% du sujet et du corps
  (translations/messages.fr.yml, translations/messages.en.yml).
  • Sujet FR : Dossier de sponsoring AFUP — EN : AFUP sponsoring file
  • Corps : « Vous avez demandé à recevoir notre dossier de sponsoring. » Le reste du
    message est inchangé ; on ne décrit pas le contenu de la pièce jointe, puisque le PDF
    reste celui uploadé sur un évènement donné.
• Pièce jointe renommée : dossier-sponsoring-afup-{fr,en}.pdf au lieu de
  forum-sponsoring-fr.pdf, pour ne plus exposer le slug de l'évènement au destinataire.
  Le chemin source sur disque est inchangé.
• Typo corrigée au passage : Best regads → Best regards.
• phpstan-baseline.php : l'entrée Cannot call method getTitle() on …Event|null
  pour SponsorshipLeadMail.php devient sans objet (les deux appels sont supprimés) et
  est donc retirée. L'entrée getPath() est conservée.

Le mail interne envoyé à sponsors@afup.org conserve le nom de l'évènement : il
indique au pôle sponsoring depuis quelle page la demande arrive, et n'est pas vu par le
prospect. À dire si l'issue visait aussi celui-ci.

Tests

tests/behat/features/PublicSite/Sponsor.feature : mise à jour du sujet attendu pour le
mail prospect dans les deux scénarios. Les assertions sur le mail interne sont laissées
telles quelles, ce qui vérifie qu'il n'a pas changé.

make cs-lint
make phpstan

Screenshots

Mail reçu par le prospect :

Avant	Après

Hors périmètre

• Le PDF est toujours stocké et uploadé par évènement (Event::getSponsorFilePath(),
  formulaire d'admin de l'évènement). Un dossier réellement mutualisé demanderait un
  emplacement unique (ex. docs/sponsoring-{lang}.pdf) et un écran d'admin dédié
  → issue séparée si le pôle sponsoring le souhaite.
• La page de remerciement (templates/event/sponsorship_file/thanks.html.twig) reste
  rattachée à l'évènement courant (layout, bouton « Découvrir l'évènement »).
• Bug préexistant repéré en testant : SponsorshipLeadMail appelle trans() sans
  locale, donc un lead qui choisit « en » reçoit un corps en français, alors que la pièce
  jointe suit bien $lead->getLanguage(). Comportement inchangé par cette PR (le sujet
  était déjà servi en FR). Correctif possible en une ligne
  (trans($id, [], null, $lead->getLanguage())) : dites-moi si vous le voulez ici ou dans
  une issue à part.