feat(controller): hot-reload the notification pipes

Email, ntfy and webhook kept their settings in a plain struct field copied at
construction, so editing controllerMethod in config.json wrote the file and
replaced the in-memory configuration while the running channels stayed on their
boot values.

Add Reload to the Controller interface and implement it for the three
notification pipes; Manager.ReloadAll fans an update out to every registered
controller and is wired into the reload hook from main.

Reload runs on the goroutine serving the settings update while the send methods
run on the status-change and incoming-webhook goroutines, so storing the new
settings in a plain field would be a data race. Each pipe publishes its settings
— and the HTTP client derived from them — through atomic pointers, and every
send takes one snapshot so a reload landing mid-send cannot split it across two
configurations.

Only a change to networkUseProxy rebuilds the client; everything else is read
from the settings at send time, so a reload that changes nothing relevant leaves
the client alone. Email needed one more fix: gomail exposes its dial hook as a
package-level variable with no unset, and the constructor only installed the
proxy dialer when the flag was set, so turning networkUseProxy off left SMTP
tunnelled through a proxy. applyEmailProxy now restores net.DialTimeout, which
is gomail's own default.

QQ (Napcat) and Telegram implement Reload because the interface requires it, but
neither can apply a change in place: the NapCat client is stopped through a
sync.Once and the Telegram polling context is created with the controller, so
both need to be rebuilt and swapped into the manager. Rather than no-op silently
and let an edit look applied, they log a warning while their settings diverge.
That rebuild is the next step.

internal/controller/controller.go

@@ -88,6 +88,15 @@ type Controller interface {
 	// IsMarkdown reports whether the channel renders Markdown, per its own
 	// "markdown" setting in config.json.
 	IsMarkdown() bool
+	// Reload applies the current configuration to a running controller, so a
+	// settings update takes effect without a restart. It reads the live
+	// configuration itself and rebuilds whatever it derived from the old one.
+	//
+	// Reload runs on the goroutine serving the settings update while the send
+	// methods may be running on others, so an implementation must not replace
+	// state those methods read without synchronizing (see the atomic pointers in
+	// the notification pipes).
+	Reload()
 	SendStatusChange(change node.StatusChange) error
 	SendServerList(onlineServers, offlineServers string) error
 	SendExecuteResult(serverName, serverUUID, command, result string) error
@@ -134,6 +143,25 @@ func (m *Manager) Register(c Controller) {
 	postLog.Info("Controller registered: " + c.Name())
 }
 
+// ReloadAll applies the current configuration to every registered controller,
+// so a settings update reaches the channels without a restart.
+//
+// The controllers are collected under the registry lock and reloaded outside
+// it: a reload can rebuild a client and block on the network, and holding m.mu
+// across that would stall every notification for its duration.
+func (m *Manager) ReloadAll() {
+	m.mu.RLock()
+	controllers := make([]Controller, 0, len(m.controllers))
+	for _, ctrl := range m.controllers {
+		controllers = append(controllers, ctrl)
+	}
+	m.mu.RUnlock()
+
+	for _, ctrl := range controllers {
+		ctrl.Reload()
+	}
+}
+
 // ShowBotInitMessage sends the bot initialization message to all enabled
 // bot controllers (QQ/NapCat and Telegram). Notification-only pipes that do
 // not implement BotController are skipped. The message is typed