Data race in ReaderImpl.AppendSlices due to unsynchronized r.slices.Back() read

[blockgroot]

Expected Behavior

AppendSlices reads and mutates r.slices under the same mutex as every other reader method (MergeSlices, ClearSlices, loadAndSubmitTasks), so concurrent calls from the queue event loop (processNewRange → AppendSlices) and the reader's own event loop (loadAndSubmitTasks) should be data-race-free.

Actual Behavior

AppendSlices (service/history/queues/reader.go:279, current main) calls r.slices.Back() before acquiring the mutex, then locks only for the subsequent PushBack. Under concurrent load this races with any locked mutator of r.slices on container/list's internal pointers, confirmed with go test -race.

Steps to Reproduce

1. Add a regression test to service/history/queues/reader_test.go that runs a goroutine locking r and calling r.slices.MoveToBack in a loop, concurrently with a goroutine calling AppendSlices in a loop.
2. Run: go test -race -tags test_dep -count=1 -run 'TestReaderSuite/TestAppendSlices_RaceWithLockedMutation$' ./service/history/queues/
3. Observe the race report: AppendSlices → container/list.(*List).Back() racing with locked MoveToBack.

Specifications

• Version: current main (ReaderImpl.AppendSlices, service/history/queues/reader.go)
• Platform: darwin/arm64, go test -race -tags test_dep