fix: don't panic RedisCache actor when result receiver is dropped

[leeguooooo]

Fixes #16.

If the caller drops the oneshot receiver before the Redis operation completes (e.g. an HTTP client disconnects mid-request), tx.send().unwrap() panics inside the actor context and the RedisCache actor dies permanently — every captcha verification on that instance then fails with Actor mailbox error until the process is restarted. We hit this in production today (details in #16).

This ignores the send result in the four RedisCache handlers, matching the existing idiom in master/embedded/master.rs (RemoveCaptcha handler). The synchronous sends in hashcache.rs are not affected: there the receiver is still in scope when send() runs, so it cannot fail.

Note: cargo check on current stable (1.96) fails on master with pre-existing never-type-fallback errors unrelated to this change; the patch compiles cleanly on 1.91.

[realaravinth]

Thanks for the bug report and the fix o/

[realaravinth]

I've manually mirrored your patch on https://git.batsense.net/mCaptcha/libmcaptcha/pulls/2. I'll merge it when CI shows green.

I'll patch libmcaptcha in cache and mcaptcha over next week. Thanks again for the patch!

[leeguooooo]

Awesome, thanks for merging it so quickly o/

Small heads-up in case it's useful: the red checks here on GitHub aren't from the patch — the .github/workflows use actions/cache@v2, which GitHub now auto-fails before the build even runs, so this PR (and any PR) will stay red on the GitHub side regardless. Your Woodpecker CI on git.batsense.net is the source of truth and it's green, so no real impact.

If you'd like, I'm happy to send a tiny actions/cache@v2 → v4 bump so the GitHub mirror goes green too — but only if it's worth your time, since you merge on Gitea anyway. Just say the word.

[realaravinth]

Thank you for the offer (and the PR). I intend to slowly move mCaptcha away from GitHub, since not US-based, and the risk of getting locked out is very real.