filesystem_store: fix emplace_file race when two writers target the same key

[erneestoc]

What

When two threads write the same blob concurrently, emplace_file() can leave one writer pointing at a deleted temp file, causing an ENOENT on rename.

The race in plain language

emplace_file() is the function that takes a freshly-written temp file and atomically moves it to its digest-keyed home in the filesystem CAS, registering it in the LRU evicting map.

1. Thread A writes blob X → calls emplace_file() → inserts entry A into the evicting map.
2. Thread B (also writing the same blob X) → calls emplace_file() → its insert replaces entry A with entry B. Replacement triggers unref() on entry A, which deletes A's temp file.
3. Thread A resumes after acquiring the write lock and checks evicting_map.get(&key).is_none() — but the key is present (entry B is there now), so the check passes.
4. Thread A proceeds to rename(temp_file → final_path) — and gets ENOENT because B's unref already deleted A's temp file.

The bug is in the existence check: it asks "is some entry present under this key?" when it needs to ask "is my entry still the one in the map?".

The fix

Replace the key-presence check with an Arc::ptr_eq check against our own entry. If the map's entry for this key isn't the same Arc we inserted, treat it the same as eviction — bail out without renaming.

let still_ours = match evicting_map.get(&key).await {
    Some(map_entry) => Arc::ptr_eq(&map_entry, &entry),
    None => false,
};
if !still_ours {
    info!(%key, "Got eviction or replacement while emplacing, dropping");
    return Ok(());
}

This is the same pattern already used downstream in the error-handling path at line 884 (Arc::<Fe>::ptr_eq), so it's not introducing a new idiom — it's making the success path consistent with the existing failure path.

Symptom this prevents

Rare ENOENT failures during CAS writes under parallel-action load on a single worker. Easy to miss because:

• It only fires when two writes for the same digest race on the same worker.
• The failure surfaces as "file not found" right after a "file written" log line, which looks like an external race or a corrupted store rather than an internal race.
• It scales with concurrent actions per worker, so it stays dormant on lightly-loaded workers and shows up under load.

Provenance

Cherry-picked from PR #2243 (commit e020168). Isolated and rebased onto current main so it can land independently of the larger PR.

Test plan

• cargo build -p nativelink-store — clean.
• cargo test -p nativelink-store --lib — green.
• cargo clippy -p nativelink-store --lib -- -D warnings — clean.
• cargo fmt -p nativelink-store — clean.
• No new test added — the existing concurrency-focused tests live in tests/filesystem_store_test.rs with substantial scaffolding; reproducing the race deterministically requires injecting an ordering hook. Happy to add one if reviewers want — open to suggestions on the right shape.

🤖 Generated with Claude Code

---

This change is