Fix reconnect goroutine leaks + only log errors after 30s of failed reconnects

[dselans]

Weekly AMQ maintenance reboots currently cause every consumer to spam errChan (which services log as errors) and leak goroutines. This PR fixes the reconnect path:

• Fixes goroutine leak in Publish() (unbuffered chanErr/chanDone + missing return meant every failed publish leaked a goroutine blocked on chanDone)
• Fixes goroutine leak in writeError() (spawned goroutines that block forever when errChan is full/unread); now a non-blocking send
• reconnect() closes the old connection if still alive, so reconnects over a live conn (force-reconnect, channel-level errors, back-to-back reconnect signals) no longer leak amqp connections + their goroutines
• New Options.ReconnectErrorAfterSec (default 30s): reconnect failures log at warn and only escalate to error after failing for 30s
• Channel setup failure after reconnect is retried instead of panicking
• Nil-acknowledger disconnects are no longer written to errChan (they are not consume errors; the watcher handles/logs reconnects)
• DefaultRetryReconnectSec lowered 60s -> 5s so services recover quickly after a reboot
• Watcher exits on Stop()/Close() instead of reconnecting a shutdown client

Tests: updated nil-ack spec for new behavior, added regression specs for both leaks, old-conn cleanup, and warn-then-error escalation (verified the publish leak spec fails against the old code).

[dselans]

ty @blinktag