Fix: Reload staging map races with apply/cancel

=== Classification
Race condition in reload state handling. Severity: medium. Confidence: certain.

=== Affected Locations
- `dnscrypt-proxy/plugin_forward.go:205`
- `dnscrypt-proxy/plugin_forward.go:228`
- `dnscrypt-proxy/plugin_forward.go:235`
- `dnscrypt-proxy/plugin_forward.go:241`
- `dnscrypt-proxy/plugin_forward.go:242`

=== Summary
`PluginForward` stores staged reload data in `plugin.stagingMap` without consistently holding `rwLock`. `PrepareReload()` writes the staged map unlocked, `ApplyReload()` reads and nil-checks it before locking, and `CancelReload()` clears it unlocked. Concurrent reload sequences can therefore race on the shared slice header, causing spurious `no staged configuration to apply` failures or applying another reload's staged rules.

=== Provenance
Verified from a reproduced finding derived from Swival Security Scanner output at https://swival.dev, then confirmed with a local concurrent reload reproducer and Go race detector evidence.

=== Preconditions
Concurrent `PrepareReload`/`ApplyReload` or `PrepareReload`/`CancelReload` calls against the same `PluginForward` instance.

=== Proof
A temporary concurrent test ran two `plugin.Reload()` loops against one `PluginForward`.
`go test -race` reported concrete races on `plugin.stagingMap`, including:
- write/write at `dnscrypt-proxy/plugin_forward.go:228`
- write/read between `dnscrypt-proxy/plugin_forward.go:242` and `dnscrypt-proxy/plugin_forward.go:235`
- write/read between `dnscrypt-proxy/plugin_forward.go:228` and `dnscrypt-proxy/plugin_forward.go:241`

A non-race execution of the same reproducer also triggered real reload failures after sufficient iterations, including spurious `no staged configuration to apply` errors and cross-application of another reload's staged rules.

=== Why This Is A Real Bug
This is not a detector-only issue. The raced value is the live reload handoff state that decides whether a staged configuration exists and which rules become active. Unsynchronized access to the slice header permits lost, stale, or mismatched staging state across overlapping reloads, directly producing incorrect runtime behavior during reachable reload paths such as file-watcher and SIGHUP-triggered reloads.

=== Fix Requirement
Guard every read and write of `plugin.stagingMap`, including existence checks and nil assignment, with the same mutex used for reload state.

=== Patch Rationale
The patch serializes all `stagingMap` access under `rwLock` in `PrepareReload()`, `ApplyReload()`, and `CancelReload()`. Moving the nil check inside the lock ensures `ApplyReload()` observes a consistent staged value, and locking the clear/write paths prevents concurrent reload operations from racing on the shared slice header.

=== Residual Risk
None

=== Patch
Patch file: `013-reload-staging-map-races-with-apply-cancel.patch`

Author: jedisct1

dnscrypt-proxy/plugin_forward.go

@@ -225,30 +225,34 @@ func (plugin *PluginForward) PrepareReload() error {
 	}
 
 	// Store in staging area
+	plugin.rwLock.Lock()
 	plugin.stagingMap = stagingMap
+	plugin.rwLock.Unlock()
 
 	return nil
 }
 
 // ApplyReload atomically replaces the active rules with the staging ones
 func (plugin *PluginForward) ApplyReload() error {
+	plugin.rwLock.Lock()
+	defer plugin.rwLock.Unlock()
+
 	if plugin.stagingMap == nil {
 		return errors.New("no staged configuration to apply")
 	}
 
-	// Use write lock to swap rule structures
-	plugin.rwLock.Lock()
 	plugin.forwardMap = plugin.stagingMap
 	plugin.stagingMap = nil
-	plugin.rwLock.Unlock()
 
 	dlog.Noticef("Applied new configuration for plugin [%s]", plugin.Name())
 	return nil
 }
 
 // CancelReload cleans up any staging resources
 func (plugin *PluginForward) CancelReload() {
+	plugin.rwLock.Lock()
 	plugin.stagingMap = nil
+	plugin.rwLock.Unlock()
 }
 
 // Reload implements hot-reloading for the plugin