Any authenticated user can revoke any other user's session (IDOR)

Any authenticated user -- a free account, a trial signup, anyone who can create an account at all -- can forcibly log out ANY other user's device at will, with no relationship to that account required, just knowledge of a family_id. At minimum this is a denial-of-service tool against specific targets; combined with any way to learn or enumerate family_id values it becomes a targeted account-disruption vector. This is a textbook IDOR (insecure direct object reference) -- the class of vulnerability where an object identifier alone, with no ownership check, is treated as sufficient authorization.

revoke_session(family_id) checks only that some refresh token exists with this family_id -- RefreshToken.query.filter_by(family_id=family_id).first() is not None -- not that it belongs to g.current_user. Any logged-in caller who supplies a valid family_id belonging to anyone passes this check and gets token_lib.revoke_family() executed against it.

1. As victim: log in, note a session/family id from GET /auth/sessions.
2. As attacker (a completely unrelated account): DELETE /auth/sessions/$VICTIM_FAMILY_ID with the attacker's own access token.
3. Observe: 200 {"message": "session revoked"} -- the victim's session is now dead, and the attacker owns none of it.

This is the highest-priority bug in this batch precisely because nothing about its symptom looks alarming in isolation -- the endpoint still returns a normal-looking 200, the request is "valid" by every surface-level measure, and the only way to notice is to specifically check whose session actually got revoked.

Compare this query against GET /auth/sessions (list_active_sessions) and DELETE /auth/sessions (revoke_all_sessions_for_user) -- both already correctly scope everything to g.current_user.id. The fix is the same shape as the query this function used to have.