Lock the round when activating it, so a double click can't create every task twice

[lgelauff]

Fixes #334 ("Photos appear in the voting sequence twice"). The main cause turns out to be a double click on
Activate, which gives every juror a second copy of every task.

What goes wrong

Activating a round creates all juror tasks inside the request, which can take seconds for a large round. If
the coordinator clicks Activate again while the first request is still running, the second request also reads
the round as paused, and creates a second full set of tasks. Nothing stops this: activate_round checks the
status without a lock, and the button stays clickable.

On production this has happened in at least 22 rounds since April 2025: every task doubled (one round tripled,
after three clicks within 18 seconds). The audit log shows two or three open_round entries a few seconds apart
for each of them. Jurors voted on both copies of almost every duplicated task, often differently, and the
round average used to decide which entries advance counts both votes.

The fix

• activate_round re-reads the round with SELECT ... FOR UPDATE before checking its status. A second
  activation waits for the first to commit, then sees the round active and gets the normal "can only activate
  round in a paused state" error.
• The Activate button is disabled while its request runs.

Tests

• New test test_concurrent_activation_creates_no_duplicate_tasks: another connection commits the round as
  active after the request has loaded it. It fails on master (the activation creates a second set of tasks)
  and passes with the fix. SQLite ignores FOR UPDATE, so the test covers the re-read; the lock itself was
  tested on MariaDB, below.
• Backend suite: 15 passed, 1 xfailed. Frontend: prettier, eslint, build clean.
• On montage-dev (MariaDB), as part of an integration branch with the pending import PRs: a double click in the UI sent one request and
  created exactly one task per entry; two activation requests sent at the same moment gave 200 and 400 (the
  second waited for the first's lock), again one task per entry.

Not in this PR

• The duplicate tasks that already exist, and finalized rounds whose results counted duplicated votes.
• Rarer ways to get a duplicate task, such as changing a round's jurors (22 duplicated tasks on production).
• If the first activation takes longer than MariaDB's lock wait timeout (50 s by default), the second click
  gets a 500 instead of the clean error. Still no duplicates. The upcoming import-worker PR turns this into a 400.

When the import-worker PR is rebased on this, activate_round conflicts: keep the import-worker version,
which has the same lock.

Written with Claude (Claude Code) on behalf of @lgelauff.

🤖 Generated with Claude Code