Roll back vote_grants audit row on dispatch failure

[AdaInTheLab]

Summary

Bug fix. Caught while finishing #48 — too late to fold in there before merge.

When `DispatchReward` throws after the audit row was inserted, the player is permanently locked out of ever claiming that vote. Every future sweep sees `HasGrantForDate=true` and short-circuits, even though no reward was ever actually granted.

This always could have happened (e.g. SQLite glitch in `AdjustPoints`), but #48's VipGift dispatch made it actually likely — a misspelled template name in the Vote Rewards settings would silently lock out every voter on that provider, with no obvious way for an admin to recover other than directly editing the SQLite database.

Fix

Narrow `try/catch` around the `DispatchReward` call only. On exception:

1. Delete the audit row via the new `IVoteGrantRepository.DeleteByKey`
2. Log a clear warning explaining the rollback
3. Return a `ClaimOutcome.Error` with the underlying message

The outer `try/catch` (network errors during `GetClaimStatus` / `MarkClaimed`) is unaffected — those failure modes don't leave an orphaned row, so they don't need rollback.

Files

File	What
`Data/Repositories/VoteGrantRepository.cs`	`DeleteByKey(provider, steamId, voteDate)`
`Features/VoteRewardsFeature.cs`	Narrow try/catch around `DispatchReward` with rollback

Test plan

• Configure 7daystodie-servers.com with reward type = VIP Gift, template name = a typo (e.g. "vote-bundlex")
• Vote at the listing site
• Sweep runs, sees the vote, attempts grant, dispatch throws because no template by that name
• Server log shows the rollback warning
• No vote_grants row left over (`SELECT * FROM vote_grants` returns zero rows for that vote)
• Fix the template name in settings
• Next sweep (or `/vote`) succeeds — no longer short-circuited
• Player gets the gift, audit row appears

🤖 Generated with Claude Code