fix: retry fscache blob cull until cachefiles completes

[Park-Jiyeonn]

Overview

Use nydusd's cull completion status during fscache teardown, and keep snapshot teardown state and blob metadata until cachefiles confirms reclamation.

Unmount EROFS before unbinding and culling, and make retries tolerate an already-unmounted mountpoint. Return a pending error without dropping the teardown marker when cull is incomplete.

Coordinate blob metadata publication with cache GC through a per-blob lifecycle. Skip a GC claim that overlaps a mount publication so a new mount cannot race with metadata removal.

Add client, teardown, pending-cull, and publication/GC lifecycle tests.

Related: Nydusd: fix: report fscache blob cull completion status #1993

Change Type

Please select the type of change your pull request relates to:

• Bug Fix
• Feature Addition
• Documentation Update
• Code Refactoring
• Performance Improvement
• Other (please describe)

[Park-Jiyeonn]

@Zephyrcf PTAL, thx!

[imeoer]

Two blockers as it stands:

1. /api/v2/blobs/cull doesn't exist in nydusd yet. Once this lands, any fscache user running a current nydusd gets a 404 out of sharedErofsUmount and the unmount fails. The nydusd side needs to be released first, and we need a fallback to the old UnbindBlob("", fscacheID) path when the endpoint isn't there.
2. Lint is red: snapshot/cleanup_queue.go:166:44: (*snapshotCleanupQueue).resume - reason always receives "fscache-cull-complete" (unparam). The branch also conflicts with main now.

Separately — this is 1200+ lines doing at least four independent things: the new cull client API, the umount/unbind reordering in sharedErofsUmount, the fscacheBlobLifecycle epoch machinery, and the cleanup queue retry. The reordering fix stands on its own and could go in right away. Would you mind splitting it out?

Also note Filesystem.RemoveCache changes signature from error to (bool, error) — that's an exported API break and should be called out in the description.