Add clarifying comments to vidMap helper functions

Added inline documentation to each helper function (addLocation, deleteLocation,
addEcLocation, deleteEcLocation) explaining the two-level locking strategy:

- RLock on vidMapLock prevents resetVidMap from swapping the pointer
- vidMap has internal locks that protect the actual map mutations
- This design provides optimal concurrency

The comments make it clear why RLock (not Lock) is correct and intentional,
preventing future confusion about the locking strategy.

weed/wdclient/masterclient.go

@@ -560,24 +560,28 @@ func (mc *MasterClient) GetDataCenter() string {
 // from swapping it during the operation. The actual map mutations are protected by
 // vidMap's internal mutex, so RLock is sufficient here for better concurrency.
 
+// addLocation adds a volume location. RLock prevents pointer swap; vidMap has internal locks for the mutation.
 func (mc *MasterClient) addLocation(vid uint32, location Location) {
 	mc.vidMapLock.RLock()
 	defer mc.vidMapLock.RUnlock()
 	mc.vidMap.addLocation(vid, location)
 }
 
+// deleteLocation removes a volume location. RLock prevents pointer swap; vidMap has internal locks for the mutation.
 func (mc *MasterClient) deleteLocation(vid uint32, location Location) {
 	mc.vidMapLock.RLock()
 	defer mc.vidMapLock.RUnlock()
 	mc.vidMap.deleteLocation(vid, location)
 }
 
+// addEcLocation adds an EC volume location. RLock prevents pointer swap; vidMap has internal locks for the mutation.
 func (mc *MasterClient) addEcLocation(vid uint32, location Location) {
 	mc.vidMapLock.RLock()
 	defer mc.vidMapLock.RUnlock()
 	mc.vidMap.addEcLocation(vid, location)
 }
 
+// deleteEcLocation removes an EC volume location. RLock prevents pointer swap; vidMap has internal locks for the mutation.
 func (mc *MasterClient) deleteEcLocation(vid uint32, location Location) {
 	mc.vidMapLock.RLock()
 	defer mc.vidMapLock.RUnlock()