fix: record votekick rate-limit timestamp only after all guards pass

[xpoes123]

In votekickInit, the 90-second rate-limit timestamp was recorded before the duplicate-votekick and eligibility checks, so a rejected initiation still consumed the initiator's full cooldown window.

Problem

In server/multiplayer/ServerMultiplayerRoomMixin.js, this.lastVotekickTime[userId] was assigned immediately after the rate-limit guard — before the loop that checks whether a votekick against the target already exists. If that loop returned early (duplicate or ineligible target), the timestamp was already written, locking the initiator out for 90 seconds even though no votekick was created.

Changes

• Moves this.lastVotekickTime[userId] = currentTime to just before the new Votekick(...) call, after all early-return guards have passed.

Risk & testing

Single-line relocation; the rate-limit guard logic and the 90-second threshold are unchanged. The cooldown now only starts when a votekick is genuinely initiated, which matches the intended behavior. semistandard and node --check pass.