[Bug] In-flight settings write can leave a replacement registration indefinitely stale

[EonHao]

Summary

A settings namespace can remain indefinitely stale when it is re-registered while the previous registration's write is waiting for persist().

Tested on master at commit 47f943859bef60e4160492346772ded9b24f765a.

Reproduction

1. Register a namespace whose current user setting is { "theme": "dark" }.
2. Start an update to { "theme": "light" } with a settings provider whose persist() is delayed.
3. Dispose the original registration while the persist is in flight.
4. Register the same namespace again before the persist completes.
5. Let the original persist finish and inspect storage, describe(), and the replacement registration.

Observed result:

replacement before persist completes: { theme: "dark" }
persisted document:                 { theme: "light" }
describe() user value:              { theme: "light" }
replacement resolved value:         { theme: "dark" }

After the in-flight write completes, the replacement registration does not converge to the value that is already on disk and in the settings document.

Expected behavior

After the in-flight write reaches storage, the current owner of the namespace should be resolved from that persisted section, so runtime state, describe(), and storage agree.

Root cause

After await this.persist(ns, section), the document cache is updated unconditionally, but the commit is skipped when the namespace owner changed. The replacement registration is not re-resolved:

deepseek-harness/packages/settings/settings/src/index.ts

Lines 634 to 643 in 47f9438

	await this.persist(ns, section)
	// The write reached storage either way; the cache must say so. Commit
	// only when this registration is still the namespace owner — a fiber
	// disposed (or replaced) mid-persist must not receive the notification.
	this.document[ns] = section
	// TODO(settings-replacement-resync): Re-resolve any replacement registration
	// from this persisted section so an old in-flight write cannot leave it stale.
	if (this.registrations.get(ns) === registration && !this.isStopped()) {
	this.bumpRevision(registration, current, section)
	this.commit(registration, next, 'update')

This can be particularly persistent for a file-backed provider if its watcher suppresses the process's own write event.

Suggested fix

After persistence, re-resolve and commit the current registration when it differs from the original registration, or serialize namespace replacement behind pending writes. A regression test should delay persist(), replace the registration, then assert that the replacement receives the persisted value.