Tell the customer when a duplicate message was not sent

[boo-code]

Questions	Answers
Description?	sendMessage() drops a message whose text is identical to the last one on the same thread and sets $mailAlreadySend, which also skips the notification e-mail. The success branch below never looks at that flag, so the customer is told "Your message has been successfully sent to our team." while nothing was stored and nobody was notified. The thread is looked up by e-mail address, so a logged-in customer always lands on their existing thread and hits this every time they resend the same text, while a guest with a fresh address never does. The success message is now only shown when something was actually sent, and a duplicate reports that it was already received.
Type?	bug fix
BC breaks?	no
Deprecations?	no
Fixed ticket?	Fixes PrestaShop/PrestaShop#33144
How to test?	Submit the front-office contact form twice from the same e-mail address with identical text. Before this change both submissions report success while only the first is stored in Customer Service and only the first sends the notification. After, the second says the message was already received. Sending a different text still works and still reports success.

What the issue says vs what is actually broken

The report blames "Server Cache ON". That is not it. Measured on 9.2 with contactform 4.4.3, submitting
the real form over HTTP:

Config	Result
PS_SMARTY_CACHE=1, PS_SMARTY_FORCE_COMPILE=1 (dev)	message stored, success shown
PS_SMARTY_CACHE=1, PS_SMARTY_FORCE_COMPILE=0 (production, never recompile)	message stored, success shown

The widget is never Smarty-cached either way: renderWidget() calls display() with no $cache_id, so
Tools::enableCache() is not reached, and Hook::coreRenderWidget() has no cache of its own. Two visitors
also get two different form tokens, so nothing is being shared.

The real defect is a silent duplicate drop that reports success. sendMessage():

// if last message is the same as new message (and no file upload), do not consider this contact
if ($lastMessage != $message || $testFileUpload) {
    ... store the CustomerMessage ...
} else {
    $mailAlreadySend = true;
}
...
if (!count($this->context->controller->errors)
    && empty($mailAlreadySend)
    && ($sendConfirmationEmail || $sendNotificationEmail)) {
    ... send the emails ...
}
...
if (!count($this->context->controller->errors)) {
    $this->context->controller->success[] = $this->trans('Your message has been successfully sent to our team.', ...);
}

The success branch never looks at $mailAlreadySend. Measured, three submissions from one email address:

send 1 (new text)        stored=1   "Your message has been successfully sent to our team."
send 2 (identical text)  stored=1   "Your message has been successfully sent to our team."   <- nothing stored, no email
send 3 (different text)  stored=2   "Your message has been successfully sent to our team."

Nothing is stored, no notification reaches the merchant, and the customer is told it arrived.

The thread is looked up by email address
(CustomerThread::getIdCustomerThreadByEmailAndIdOrder($from, $id_order)), which is why @pollat sees it for
logged-in customers: their address is prefilled, so they always land on their existing thread, while a guest
typing a fresh address gets a new thread and always succeeds. That is their "if logged user use prestashop
contact form, no mail are recived by admin ... if not logged user send mail by contact form, the mail arrive".

The fix

Report what actually happened. The de-duplication is left as it is.

if (!empty($mailAlreadySend)) {
    $this->context->controller->success[] = $this->trans(
        'This message has already been sent to our team.', [], 'Modules.Contactform.Shop'
    );
} else {
    ... the existing message ...
}

After:

send 1 (new text)        stored=1   "Your message has been successfully sent to our team."
send 2 (identical text)  stored=1   "This message has already been sent to our team."
send 3 (different text)  stored=2   "Your message has been successfully sent to our team."

Mutation check: with the unpatched module back in place (verified by grep), both sends report
"successfully sent" while only one is stored.

Adds one new translation string in Modules.Contactform.Shop.

Deliberately left for a maintainer decision

The de-duplication compares only against the last message on a thread, and the thread never expires. So a
customer who writes the same sentence months apart is still silently de-duplicated, and the merchant is never
told. Whether that rule should have a time window, or should notify anyway, is the specification this issue is
labelled as needing. Raised in the issue comment; not changed here.

Conflict check

Only open PR touching contactform.php is #100 (Hlavtox, "Release version 4.4.4", base master), whose
hunk is at @@ -530 - the user_agent length change, already present on dev. This change is at ~line 668 on
dev. No overlap, and different base branches.

Verification

• php -l clean
• Behaviour measured over real HTTP against the running 9.2 shop, before and after, three-message sequence
• Cache setting tested both ways to rule out the reported cause
• Shop restored to the pristine 4.4.3 module afterwards; probe threads and messages deleted and verified at 0