fix(cli): stabilize dispatch retention after lock contention

[limityan]

Summary

• explicitly release JobLock through fs2::FileExt::unlock before the backing file handle is closed
• verify a contended job lock can be reacquired after the holder is dropped
• retry retention cleanup within a bounded deadline when Windows briefly keeps job files busy

Root cause

The GitCode Windows pipeline exposed a timing-dependent failure in retention_skips_contended_job_without_blocking_and_retries_later: the first collection correctly skipped the locked job, but the single immediate retry returned 0 instead of 1.

Retention already treats Windows PermissionDenied rename failures as retryable and defers cleanup to a later collection. The test assumed that "later" meant the very next call, while JobLock also relied on implicit handle-close semantics instead of explicitly releasing its fs2 lock. Under transient Windows file contention, those assumptions made the test flaky.

This keeps retention non-blocking and preserves its existing eventual-cleanup behavior. It does not change storage schemas, lock paths, public APIs, or job lifecycle semantics.

Verification

• cargo check --locked -p bitfun-cli
• cargo test --locked -p bitfun-cli (503 unit tests and all CLI integration suites passed)
• focused contended-retention and Windows sharing-violation tests
• contended-retention regression repeated 200/200 times
• the corresponding GitCode bitfun_ci run passed ohos_arrch64, macos_arm64, and cargo-test

The original failure is timing-dependent and may pass locally on the unmodified code; the remote Windows failure is the observed regression evidence.