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/verified_account_required.feature

@@ -25,6 +25,11 @@ Feature: Protected article routes and the offline-inclusive listing require a ve
       features/cancel_pending_registration.feature); those two handlers are updated to call the
       shared helper, and their observable 401 behavior on a missing or non-numeric user_id claim
       is unchanged
+    And claims.UserId now also rejects a "user_id" claim whose JSON number is not a whole value in
+      the inclusive range 0 to 4294967295 (math.MaxUint32): a negative number, a value with a
+      fractional part (e.g. 7.5), or a value larger than 4294967295 all now return ok=false instead
+      of being silently truncated or wrapped into a uint32 that could coincidentally match a
+      different, real user id
     And when claims.UserId reports no usable user_id, RequireVerifiedUser answers 401 with
       apperr.UnauthorizedErrorMessage without calling GetUserUseCase, the same body and status the
       protected auth routes already use for the same condition
@@ -108,6 +113,17 @@ Feature: Protected article routes and the offline-inclusive listing require a ve
       | a validly signed jwt cookie whose claims carry no "user_id" key at all             |
       | a validly signed jwt cookie whose "user_id" claim is the string "one"              |
       | a validly signed jwt cookie whose "user_id" claim is the number 999, which does not match any user |
+      | a validly signed jwt cookie whose "user_id" claim is the number -1                                 |
+      | a validly signed jwt cookie whose "user_id" claim is the number 4294967296 (one past the uint32 max) |
+
+  Scenario: A fractional user_id claim is never truncated into impersonating a different real user
+    Given a user repository containing user id 7, is_verified true
+    And a validly signed jwt cookie whose claims are {"user_id": 7.5}
+    When the client sends POST /v1/article/ with that cookie and body
+      {"title": "Valid Title", "body": "Some content"}
+    Then the response status is 401
+    And the response body is the apperr.UnauthorizedErrorMessage text
+    And no article was created
 
   Scenario Outline: A request with no jwt cookie is still refused with 401, never 403
     Given no jwt cookie is sent