db: `View`/`Update`/`Write` race with `Close()` — no lock or closed-check

Summary

The View, Update and Write helpers on the pebble, pebblev2 and memory backends don't guard against a concurrent Close(), unlike the other public DB methods (Get, Has, NewIterator, ...).

Surfaced by Copilot review on #3846 — the problem predates that PR (it only added snapshot cleanup), so it's tracked here separately.

Details

pebble / pebblev2 (db/pebble/db.go, db/pebblev2/db.go):

• View neither takes closeLock nor checks d.closed, so calling it concurrently with Close() makes pebble.DB.NewSnapshot() panic on a closed DB instead of returning pebble.ErrClosed.
• Update/Write do check d.closed, but without holding closeLock, so the check itself is racy and the batch can still be created/committed while Close() runs.

memory (db/memory/db.go):

• View reads d.db and NewSnapshot panics on d.db == nil without holding d.lock, while Close() writes d.db = nil under the lock — a data race the race detector can flag. Update/Write have the same unguarded check.

Suggested fix

Mirror the Get/Has pattern: take closeLock.RLock() (resp. d.lock.RLock() in memory), check the closed flag, and hold the lock for the duration of the callback so Close() blocks until in-flight transactions finish.

One pitfall in the memory backend: NewSnapshot() → Copy() takes d.lock.RLock() itself, so naively grabbing RLock in View before calling it is a recursive read-lock — a documented deadlock when a writer is waiting in between. The copy needs to happen under a single lock acquisition (e.g. an unexported unlocked copy helper).

Start with the Get/Has and Close implementations in db/pebble/db.go, db/pebblev2/db.go, and db/memory/db.go, then trace View, Update, and Write. Use the race detector while exercising concurrent operations and closing. Done means these helpers no longer panic or race with Close, and in-flight callbacks finish safely before closing.