Blob cleanup task fails due to long file paths (file name too long)

### Is your feature request related to a problem? Please describe.

Yes. I'm always frustrated when the **background Blob cleanup task fails repeatedly** with the error `file name too long`. This happens frequently in enterprise/government scenarios where file paths contain multiple levels of Chinese directories and very long filenames (e.g., `永平县医保保障局关于2026年企业职工基本养老保险...的通知.docx`).

As a result:
- Deleted files' blob data is never cleaned up → wasted storage space.
- The entire cleanup task fails, even if only one file has a long path.
- No automatic recovery or skip mechanism exists.

This appears to be caused by Linux filesystem path length limits (typically 4096 bytes), which are hit when Cloudreve tries to delete deeply nested or long-named files under `/cloudreve/data/uploads/`.

### Describe the solution you'd like

I’d like Cloudreve Pro to handle long file paths gracefully during Blob cleanup:

1. **Pre-check path length**: Before calling `remove`, check if the full path exceeds a safe threshold (e.g., 3500 bytes).
2. **Auto-rename or truncate**: If too long, temporarily rename the file to a short UUID or truncated name (e.g., `longfile_..._a1b2c3.docx`) before deletion.
3. **Fail-safe processing**: If deletion still fails, log the error with Blob ID and **skip that item**, allowing the rest of the cleanup job to continue.
4. **Configurable tolerance**: Add a config option like:
```yaml
blob_cleanup:
max_path_length: 4000
skip_on_long_path: true

**Describe alternatives you've considered**
Deployment: Synology SA6400, DSM 7.2.2-72803
Runtime: Docker Compose with cloudreve.azurecr.io/cloudreve/pro:latest
Storage: Local volume mounted at /volume1/cloudreve
Database: PostgreSQL

**Additional context**
The task failure logs clearly show:
remove /cloudreve/data/uploads/...: file name too long
with full paths exceeding 400+ characters.

In real-world usage, long filenames are unavoidable. A production-grade cloud storage system should handle them without failing critical maintenance tasks.