fix(backend): only touch NNTP pool when provider list changes

[javi11]

Summary

Saving any configuration was unnecessarily invoking UpdateConfig on the NNTP pool, and a stale recovery path in Manager.UpdateConfig could leak a distinct verify pool. This restricts pool churn to genuine provider-list changes and hardens the recovery path.

What changed

• internal/backend/config.go — poolConfigChanged now matches servers by canonical providerKey (reordering is a no-op) and delegates field comparison to pool.ServerConfigChanged, so the "what counts as a provider change" rule lives in one place. Removed the ConnectionPool.MinConnections / HealthCheckInterval comparison: those are nntppool.NewClient construction options that can't be applied to a running client by AddProvider/RemoveProvider, so including them only caused wasted updates. applyConfigChanges is now a switch and only calls pool.New when poolManager == nil and servers are configured.
• internal/pool/manager.go — Exported ServerConfigChanged and ProviderKey. Fixed UpdateConfig's nil-pool recovery: it used to unlock, call New, relock, and overwrite both pool fields without closing whatever was there (leaking any distinct verify pool, and racing with concurrent Close). It now builds the clients in place under the lock and closes any leftover upload/verify pools before overwriting.

Why

1. Per the user's requirement, only changes to the providers list should touch the NNTP pool — non-provider config (Posting, Watcher, Queue, etc.) must not.
2. Provider updates must continue to use nntppool's AddProvider / RemoveProvider, never destroy-and-recreate the running client. The diff path in Manager.UpdateConfig already does this; this PR just stops calling it for unrelated saves.

Reviewer notes

• ConnectionPool.MinConnections and HealthCheckInterval now require an app restart to take effect. Documented in a comment on poolConfigChanged.
• The first-time pool creation path (after the setup wizard adds the first server) still fires pool.New exactly once — that's expected, the manager is nil at that point.

Test plan

• go build ./... and go vet ./internal/backend/... ./internal/pool/... are green (verified locally).
• Save a non-pool field change (e.g. Posting.MaxRetries) → logs show Pool configuration unchanged, skipping pool update and the running nntppool.Client is preserved.
• Add a server → logs show Added provider to pool for the new provider only; no pool.New invocation.
• Edit an existing server's password → logs show Removed provider then Added provider for the same key.
• Reorder servers without other changes → no pool update logged.
• Delete all servers, then re-add one → first-time creation branch fires exactly once.