SearchIndex.drop_keys does not validate cluster hash-tag co-location (inconsistent with drop_documents)

Current behavior

SearchIndex.drop_documents (redisvl/index/index.py:840) explicitly validates that all keys share a hash tag before calling delete:

if isinstance(self._redis_client, RedisCluster) and not _keys_share_hash_tag(keys):
    raise ValueError("All keys must share a hash tag when using Redis Cluster.")
return self._redis_client.delete(*keys)

SearchIndex.drop_keys (redisvl/index/index.py:826) does not. On a clustered Redis Enterprise database, a multi-key DEL whose keys do not all hash to the same slot raises CROSSSLOT from the server — but only some redis-py client modes surface this cleanly. In others the call partially succeeds or fails opaquely.

Proposed change

Apply the same hash-tag check in drop_keys that drop_documents already applies, or factor the check into a shared helper called by both. Behavior on cluster should be identical between the two methods.

Why this surfaces

SemanticCache.drop() uses drop_keys under the hood for the keys= argument path and uses drop_documents for the ids= argument path. The two argument paths therefore behave differently on cluster, which is a footgun for customers building invalidation jobs that take whichever shape comes from their query results.

Notes

Surfaced while writing a scoped semantic caching architecture spec.

Start in redisvl/index/index.py at SearchIndex.drop_keys (around line 826) and compare it with drop_documents (around line 840), including the existing RedisCluster hash-tag validation. Ensure both methods have identical cluster behavior: invalid cross-slot keys should raise the stated ValueError before delete is called.