Implement lost password procedure

[Mips2648]

Description

This PR adds a complete password reset flow from the login page.

Users can now request a password reset link from the “forgot password” screen. When a valid reset link is opened, Jeedom displays a dedicated password reset form, validates the new password confirmation, and submits the reset using the token from the URL.

The backend now generates short-lived reset tokens, validates token lifetime explicitly before changing the password, rejects password reset attempts for system users, and removes consumed or expired tokens. Reset requests are also throttled per IP address to prevent repeated notification attempts while keeping the client response generic.

Suggested changelog entry

Ajout d’une fonctionnalité de réinitialisation de mot de passe par lien sécurisé avec expiration, limitation par IP. L'utilisateur doit avoir configuré une commande de notification dans son profil pour que cela fonctionne.

Related issues/external references

Fixes #3518

Types of changes

• Bug fix (non-breaking change which fixes)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

[Salvialf]

Nice work on this one, it's a feature that was really missing and the integration fits well into the existing login page.

Pushed my review fixes on the branch, one commit per topic:

• Fixed the lost/reset password forms showing at the bottom of the card, plus markup cleanup (hidden class, no tabindex, duplicated id)
• Doc links via jeedom::getDocUrl() (develop merged) and clearer labels
• Reset link forces v=d, phones were redirected to the mobile UI which ignores rpk
• Fixed Enter sending every request twice (native form submission + keypress handler), which also fixes Enter in the forced password change
• Added missing log translations, info entries moved to log::audit()
• Disabled users can no longer request a reset, like login()
• Same response time on every path: the "link sent" path had no delay and answered almost instantly, revealing valid logins
• Throttled requests now return an explicit "too many requests" error instead of the success message: the limit is per IP so it reveals nothing about logins, and the instant response already gave it away

Left to you: the warning logs (log::audit() is always info, default level 400 hides audit entries), and $current_ip = getClientIp() in askPassword (core/ajax/user.ajax.php) to switch to network::getClientIp() in #3532. LDAP and the internal/external link address are deferred as discussed.

Out of scope here: no password change (profile, users page, this reset, jeecli) revokes existing sessions or registered devices, to be handled globally in a later PR.