Let a voter change their vote, safely under concurrent requests

Once a user votes on a poll today, that choice is permanent, which is a real usability gap for anything resembling a genuine survey or prediction market -- a voter who changes their mind, or fat-fingered their first tap, has no way to correct it short of contacting a moderator. Any fix has to hold up under the same kind of concurrency this app is built to take seriously: a slow UI where someone double-clicks a new choice, or a retried request after a flaky connection, must never leave a voter with zero votes or two votes on the same poll, even briefly.

Once a user votes on a poll, that choice is permanent -- there is no way to change it. polls/models.py's UniqueConstraint(fields=["user", "poll"]) guarantees at most one Vote row per user per poll, and PollViewSet.vote (POST) is the only way to write one; a second POST from the same user is rejected with 409 (see polls/services.py::cast_vote). /api/polls/{id}/vote/ currently only routes POST -- there is no PATCH handler at all, so a PATCH request today returns 405 Method Not Allowed. No stub is provided for this ticket -- the feature is entirely absent, and both tests exercise the endpoint directly over HTTP.

cd django/poll_app source .venv/bin/activate python manage.py runserver &

Register a user, vote once (POST succeeds, 201), then try to change it:

curl -s -o /dev/null -w "%{http_code}\n" -X PATCH http://127.0.0.1:8000/api/polls/1/vote/
-H "Authorization: Token $TOKEN" -H "Content-Type: application/json" -d '{"option": 2}'

-> 405 Method Not Allowed -- there is no PATCH handler on /vote/ at all yet.

This is the concurrency-safe counterpart to polls/tests/test_race.py's lesson, applied to an update instead of a first-time insert. The naive approach -- "delete the old Vote, then create a new one" -- is exactly the kind of thing that reads cleanly and passes a quick manual check, and is wrong under concurrency: two near-simultaneous change requests can interleave their delete/create pairs so that, at some point during the race, either zero Vote rows exist (a small window where the user "looks like" they haven't voted at all) or two Vote rows briefly or permanently exist (violating the very constraint the rest of this app is built around). A single atomic UPDATE-style operation on the existing row avoids that window entirely -- but you have to reach for it deliberately, since "delete, then create" is the more obvious first instinct.

Look at how cast_vote in polls/services.py currently handles a new vote (checking is_active, then relying on the database to reject a duplicate). A vote change isn't a new insert at all -- it's a modification of the row that the UniqueConstraint guarantees already exists exactly once. Think about what a single, atomic write against that existing row looks like (something that changes option in place, in one statement, rather than two separate delete-then-create statements with a window in between), versus what would need to happen if you insisted on a check-then-act shape. For the view side, PollViewSet.vote is currently declared with methods=["post"] only -- the same @action route-sharing mechanism that lets a GET handler share /vote/'s URL (see the my-vote-lookup ticket) applies here for PATCH too.