fix(redis): always prefix clear_pattern patterns that start with the key prefix

[allen0099]

Closes #109.

Problem

AsyncRedisCacheBackend.clear_pattern removed the backend key prefix from any pattern that started with it. A logical key that itself starts with the prefix could therefore never be matched. With key_prefix="cache:" and the default CacheManager (whose keys also start with cache:), CacheManager.clear_pattern("user:*") sends cache:user:*, which was stripped to user:* and cleared nothing, although cache:cache:user:1 existed.

The code has changed since the issue was written (it now uses removeprefix rather than skipping the prefix), but the outcome is the same.

Change

• The pattern always matches the logical key: the escaped prefix is always added, as on the memory backend and as the base docstring says.
• Compatibility: when that clears nothing and the pattern starts with the prefix, the old stripped form is tried. If it clears anything, a DeprecationWarning names the pattern to pass instead. 0.4.0: remove the Redis clear_pattern prefix fallback #125 removes the retry in 0.4.0.
• docs/BACKENDS.md and the changelog (Fixed and Deprecated) describe both.

One edge case keeps the 0.3.7 behaviour: a pattern that starts with the prefix and matches nothing under the new rule still falls back to the stripped form. That is exactly what 0.3.7 did for every such pattern, and it now warns.

Tests

• test_redis_cache_manager_clear_pattern_with_matching_prefixes: the reproduction from the issue.
• test_redis_clear_pattern_prefixes_a_pattern_that_starts_with_the_prefix: a key that starts with the prefix is cleared, a key without it is kept, and no warning is emitted.
• test_redis_clear_pattern_with_prefixed_pattern and the glob-prefix test now expect the DeprecationWarning.

With the fix reverted, those four tests fail. The full suite passes against live Redis and Memcached (CACHEX_REQUIRE_LIVE_SERVERS=1): 792 passed. mypy --strict is clean.