[2.x] Fix hasUpvoted/hasDownvoted reflecting another user's vote (#135)

[imorland]

Fixes #135

Problem

hasUpvoted / hasDownvoted on a discussion's firstPost (and on posts) are derived from $post->actualvotes->first(), which assumes the only vote present is the current actor's.

That holds on the discussion list, where firstPost.actualvotes is eager-loaded with a where('user_id', actor) constraint. But on the single-discussion (show) endpoint the relation is unconstrained, so ->first() returns whichever row sorts first by the (user_id, post_id) index — i.e. another user's vote. The actor then sees someone else's vote state.

Example: the actor upvotes a first post that another user (with a lower user_id) downvoted → the show endpoint reports hasUpvoted=false, hasDownvoted=true.

This is the same class of bug as #134; that fix was lost when AddPostData was refactored into the resource-field classes for 2.x.

Fix

Derive the value from the actor's own vote with firstWhere('user_id', $actor->id) in both DiscussionResourceFields and PostResourceFields, so correctness no longer depends on how actualvotes was loaded.

Tests

Adds integration tests asserting that, with multiple users' votes on the first post, both the discussion list and show endpoints reflect only the actor's own vote. The show test fails without this change.