Must not modify the_index.cache as it may be passed to realloc at some point.
The index cache is not static, growing as new entries are added. If entries are added after prune_cache is called, cache will no longer point at the base of the allocation, and realloc will not be happy.
I verified that this was the only place in the current source which modified any index_state.cache elements aside from the alloc/realloc calls in read-cache by changing the type of the element to 'struct cache_entry ** const cache' and recompiling.
A more efficient patch would create a separate 'cache_base' value to track the allocation and then fix things up when reallocation was necessary, instead of the brute-force memmove used here.