Fix issue 370 temp-directory lock cleanup races (suggestions 2 and 3)

[jaredpar]

Why

Two unit tests (CompilerLogReaderTests.ReadCompilerCallWrongOwner and ProjectReferences_Corrupted) fail intermittently on windows-latest under parallel load. Neither touches the lock system directly; they fail because every LogReaderState using the default shared temp directory participates in the locks/ cleanup protocol from #366/#367, which has file-sharing races. This implements suggestions 2 and 3 from #370.

What changed

Atomic lock lifetime (suggestion 2). The <guid>.lock file is now owned for the instance lifetime and its removal is tied to the handle:

• On Windows it is opened with FileOptions.DeleteOnClose, so the file is removed atomically when the handle closes (including on a hard crash, where the kernel enforces it). This removes the release-then-File.Delete window in Dispose that let cleanup race with disposal.
• On Unix DeleteOnClose is deliberately not combined with FileShare.None, because that silently disables share enforcement (On Linux, FileShare.None doesn't seem to be taken into account when retrying to open a locked file dotnet/runtime#59995) and would let the cleanup probe delete a live owner's directory. Instead the lock is a plain FileShare.None handle deleted manually in Dispose; Unix has no delete-pending semantics so that delete is race-free.

Crash-safe staleness probe. CleanupStaleTempDirectories now treats a directory as orphaned when its lock file is missing, or exists but can be opened exclusively. A successful exclusive open is a reliable liveness test on both platforms because the OS releases the share lock when the owning process dies. Directories whose lock is still held by a live owner are left alone.

No Debug.Fail on best-effort cleanup (suggestion 3). The two Debug.Fail calls in Dispose are downgraded to silent best-effort no-ops so expected concurrent-cleanup failures never assert in Debug/CI.

Tests in CommonUtilTests and LogReaderStateTests are updated to the probe-based semantics (unheld lock file => delete, held lock file => skip).

Notes for reviewers

• The Unix DeleteOnClose + FileShare.None interaction (On Linux, FileShare.None doesn't seem to be taken into account when retrying to open a locked file dotnet/runtime#59995) is the non-obvious part; there are comments in the ctor and probe explaining why the two platforms differ so nobody re-adds DeleteOnClose on Unix. Windows validated locally (targeted + full net10.0 suite); Linux share enforcement is validated by CI.
• Scope is intentionally limited to suggestions 2 and 3. During stress testing I reproduced a separate, pre-existing race (Race A): concurrent deletion of the shared locks/ directory mid-construction throws DirectoryNotFoundException/UnauthorizedAccessException when opening the lock file (deterministically 555 errors in a 16-thread harness, 0 after applying suggestion 1). Fixing that requires suggestion 1 (stop deleting the shared locks/ directory), which is not included here. Without it the original flaky tests can still intermittently fail, so a follow-up for suggestion 1 is recommended.

[codecov]

Codecov Report

❌ Patch coverage is 74.19355% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.75%. Comparing base (c962bb4) to head (99bd53a).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/Basic.CompilerLog.Util/LogReaderState.cs	64.28%	4 Missing and 1 partial ⚠️
src/Basic.CompilerLog.Util/CommonUtil.cs	82.35%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #371      +/-   ##
==========================================
- Coverage   95.76%   95.75%   -0.01%     
==========================================
  Files          56       56              
  Lines        7786     7803      +17     
  Branches      907      911       +4     
==========================================
+ Hits         7456     7472      +16     
- Misses        186      187       +1     
  Partials      144      144              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.