Invalidate stale caches after cloud mutations

[terminalchai]

Deleting or moving a cloud object can leave stale cached files behind. Recreating the source with exclusive mode can then raise FileExistsError, and append can reuse deleted content. External cloud deletions cause the same problem.

Clear obsolete caches after successful unlink, rename/replace, move/move_into, rmdir and rmtree operations, including ADLS Gen2 directory renames. Moves invalidate both source and destination caches. Failed mutations and self-moves preserve their caches. When a remote file is missing, refresh discards its clean cached file while retaining directory contents and same-path pending writes using the existing _dirty flag.

Closes #388.

The full mocked/local suite passes on Windows/Python 3.11: 2,369 passed and 127 skipped across all provider rigs. Black, flake8, mypy (31 source files), source/wheel builds, the regenerated MkDocs documentation and diff checks pass. Independent specification and code-quality reviews found no remaining actionable findings. Live cloud backends were not tested locally; fork live CI requires maintainer approval.

Contributor checklist:

• Read and understood CONTRIBUTING.md
• Existing issue and Closes #388 in the summary
• Incorporated current master
• Failure-before / success-after evidence for cache invalidation
• Provider-agnostic behavior with ADLS-specific directory rename handling
• Manual live cloud backend testing
• Added regression tests
• Lint and mocked/local tests pass
• HISTORY.md includes issue Methods that move/remove files on the cloud don't remove the cached version #388 and PR Invalidate stale caches after cloud mutations #600

Prepared with Codex assistance, including automated implementation and independent automated reviews. Local validation results are reported above.

[pjbull]

Thanks! A few other removals still leave the cache in place, so the same FileExistsError and stale append can still happen. Let's get those as part of this as well.

• Clear both caches in same-client move / move_into. They call client._move_file from _copy (cloudpathlib/cloudpath.py:1385) and never enter replace, so the source cache stays after the object is gone.
• Clear both caches on ADLS Gen2 directory rename. AzureBlobPath.replace (cloudpathlib/azure/azblobpath.py:90) catches CloudPathIsADirectoryError and returns client._move_file directly, so nested cached files survive the rename.
• In _refresh_cache (cloudpathlib/cloudpath.py:1713), delete a non-dirty local file when stat() raises NoStatError. That is the backstop from the issue thread, and it covers deletes made outside these methods. We should clear the cache when we catch NoStatError
• Add tests for same-client move / move_into, an ADLS Gen2 directory rename with a cached nested file, and client._remove followed by open("x") and open("a") with no cloudpathlib mutation in between.

[pjbull]

We should check if the cache actually has content that may need to still be uploaded with something like.

existed = self.exists()
self.client._remove(self, missing_ok)
if existed or not self._dirty:
    self.clear_cache()

An explicit unlink of an object that is there should still clear a dirty cache.

[pjbull]

Add this PR number to the bullet.

[pjbull]

_dirty_cache_files machinery is a separate feature that we could consider separately, but I don't want to implement as part of this fix. could you extract that and just keep the pieces that fix the current issues? thanks!