fix: remove the unused user use cases, fix the specs that no longer match the code, include api/middleware and api/pkg/claims in mutation testing, log failures that password reset requests currently ignore, and reject user_id claims that don't fit a user id

features/request_password_reset.feature

@@ -48,6 +48,11 @@ Feature: Anyone can request a password reset, and the response never reveals whe
       code, to store it, or to send the email is swallowed the same way a not-found email is, so the
       handler can never tell those cases apart either — sending the request always looks the same to
       the caller regardless of whether the email exists or whether the mail send happened to succeed
+    And a failure to hash the code, to store it, or to send the email is now also written to the
+      process log via the stdlib log package (the same convention
+      internal/infrastructure/mailer/mailRepository.go already uses for its own send failures);
+      this is in addition to, not instead of, always returning nil to the caller — the HTTP response
+      is unaffected by whether a failure occurred or was logged
     And a reset applies the same way regardless of the user's IsVerified status: an unverified user
       can request and receive a password reset email exactly like a verified one, since resetting a
       password is unrelated to email verification
@@ -104,6 +109,7 @@ Feature: Anyone can request a password reset, and the response never reveals whe
     Then the response status is 200
     And the response body is {"message": "If an account exists for that email, a password reset link has been sent."}
     And no jwt cookie is set
+    And a failure was written to the process log naming the mail-send failure
 
   Scenario: An unverified user can request a password reset exactly like a verified one
     Given the user repository contains a user "bob" with email "bob@example.com" and IsVerified false
@@ -148,3 +154,24 @@ Feature: Anyone can request a password reset, and the response never reveals whe
     When RequestPasswordReset is called with "alice@example.com"
     Then the call returns nil
     And the fake repository's UpdatePasswordResetCode method was invoked exactly once with userId 3
+    And a failure was written to the process log naming the mail-send failure
+
+  Scenario: The use case logs and swallows a hashing failure
+    Given a user.Repository fake containing user id 3, email "alice@example.com"
+    And a RequestPasswordResetUseCase built directly over that fake, a hasher set to fail on its
+      next Hash call, and a mail.Repository fake
+    When RequestPasswordReset is called with "alice@example.com"
+    Then the call returns nil
+    And the fake repository's UpdatePasswordResetCode method was never invoked
+    And no email was sent
+    And a failure was written to the process log naming the hashing failure
+
+  Scenario: The use case logs and swallows a repository failure while storing the reset code
+    Given a user.Repository fake containing user id 3, email "alice@example.com", set to fail on
+      its next UpdatePasswordResetCode call
+    And a RequestPasswordResetUseCase built directly over that fake, a hasher, and a mail.Repository
+      fake
+    When RequestPasswordReset is called with "alice@example.com"
+    Then the call returns nil
+    And no email was sent
+    And a failure was written to the process log naming the storage failure