Fix FileStorageKey dropping writes under an immediate scheduler

[mAu888]

Summary

FileStorageKey's .didSet debounce can get permanently stuck so that every save after the first is buffered but never persisted — whenever the backing storage uses an immediate scheduler. That's the default under test, where defaultFileStorage resolves to .inMemory (scheduler: .immediate).

A long-lived @Shared masks this, since its in-memory value stays correct. But a short-lived @Shared — e.g. one declared inside a dependency-client closure and recreated across await points — deinits between uses, discards the buffered write, and the next reference reloads a stale value from storage. Under parallel Swift Testing this looks like cross-@Test @Shared "bleed", but per-test isolation is actually intact; the write is dropped within a single test.

Root cause

save(_:context:continuation:) arms the debounce work item and schedules it while still inside state.withValue { … }:

try state.withValue { state in
  …
  state.workItem = workItem
  storage.asyncAfter(.seconds(1), workItem)   // scheduled inside the lock
}

With .immediate, asyncAfter runs the work item synchronously and re-entrantly. Because LockIsolated.withValue is copy-and-write-back…

var value = self._value
defer { self._value = value }   // restores the outer copy on exit
return try operation(&value)

…the re-entrant work item's state.workItem = nil is clobbered by the outer scope's write-back. state.workItem then stays non-nil forever (the one-shot work item has already run), so every later .didSet save takes the buffering else branch and nothing is ever written.

Production (.fileSystem → DispatchQueue.main) is unaffected: there the work item is genuinely deferred and runs outside the lock.

Fix

Return the work item from state.withValue and call storage.asyncAfter after the lock is released, so it can't run re-entrantly under the lock. Deferred behavior is unchanged; the immediate scheduler now persists every write.

Tests

Adds immediateSchedulerPersistsConsecutiveWrites: two consecutive .didSet writes under .immediate must both persist. It fails on main and passes with the fix. The existing throttle / noThrottling debounce tests are unchanged.

Reproduction

The bug reproduces deterministically with two consecutive writes — no concurrency required:

@Test func consecutiveWritesArePersisted() async throws {
    @Shared(.fileStorage(.store)) var items = [Int]()

    $items.withLock { $0.append(1) }
    $items.withLock { $0.append(2) }

    try await $items.load()   // reload from storage

    #expect(items == [1, 2])  // ❌ 2.8.0: items == [1]
}

Standalone repro repo (deterministic test; main reproduces, the with-fix branch points at this fix and passes), with full trace and root-cause analysis: https://github.com/mAu888/swift-sharing-testing-issue

Its CI shows the contrast directly:

• ❌ Bug reproduced on main (released 2.8.0): https://github.com/mAu888/swift-sharing-testing-issue/actions/runs/26781467352
• ✅ Passing against this fix (with-fix branch): https://github.com/mAu888/swift-sharing-testing-issue/actions/runs/26781476410

Possibly related: #108.

[mAu888]

I've updated the PR as there is an easier way to reproduce the issue. First, I thought #214 was fixing the issue. But I've pinned the example repo to swift-sharing@main and it continues to fail (also with the simplified example). See https://github.com/mAu888/swift-sharing-testing-issue/actions/runs/26781956782/job/78948233737

Let me know if there is anything missing from this PR that would make it ready to merge, or what your point of view is on the underlying issue.

[mbrandonw]

Sorry, my last message mentioned a deadlock, but in reality it's just a slow test. We'll look into this more soon. Thanks!