[BUG]: Guarantee FUSE handle cleanup when release paths become stale [LiAuto]

[yangcx000]

Describe the bug

release reconstructs the inode path before calling release_handle. If an inode ancestor has been evicted from dcache, path reconstruction returns early and the handle is never removed. Its writer is neither completed nor cancelled, and deferred deletion is skipped.

This can leak handles and writers and can lose buffered data.

To Reproduce

1. Open a file with a writer.
2. Unlink the file while keeping the handle open.
3. Continue writing and wait beyond node_cache_ttl so an empty ancestor can be evicted.
4. Close the file.
5. Observe path reconstruction fail before handle cleanup.

Expected behavior

Every release path must remove the handle exactly once and complete or safely cancel its writer even when dcache path reconstruction, lock cleanup, or deferred deletion fails.

OS Version (please complete the following information):

• Linux
• Curvine branch: current main
• Component: curvine-fuse handle/dcache lifecycle

Additional context

Goal:

• Retain a stable release path or backend identity in the handle.
• Reorder release into a finally-style cleanup flow.
• Preserve the first operation error without skipping later resource cleanup.
• Add open → unlink → write → cleaner → release regression coverage.

Not goal:

• A complete redesign of all inode references, hardlinks, and request ordering.

Related: #1221 tracks retrying cleanup after cleanup work itself has failed. This issue covers the earlier path-reconstruction return that can prevent cleanup from starting at all.