Postgres connection pool leak on every StartClient/reconnect cycle

pkg/whatsmeow/service/whatsmeow.go から始め、StartClient 内の sqlstore.New と、そこに再び入る ReconnectClient および kill-channel のパスに焦点を当てます。Postgres に対して問題を再現し、再起動サイクルを繰り返した際のアイドル接続を pg_stat_activity で調査します。繰り返しの再接続または QR teardown サイクルによってプールが蓄積したり max_connections を使い果たしたりしなくなれば完了です。

Bug: Postgres connection pool leak on every StartClient/reconnect cycle

Commit: 9337afc (branch main, tag ~0.7.2)
File: pkg/whatsmeow/service/whatsmeow.go

Description

StartClient calls sqlstore.New(context.Background(), "postgres", w.config.PostgresAuthDB, nil) (lines ~322/329) to build the whatsmeow auth *sqlstore.Container on every invocation. This opens a brand new *sql.DB connection pool each time. container.Close() is never called anywhere in the file (confirmed with a full-file search).

StartClient is re-entered on:

• ReconnectClient (line ~174), which calls StartInstance → StartClient again
• the kill-channel branch of StartClient's own select loop (line ~629), which unconditionally calls w.StartClient(cd) again on any kill signal, not just genuine reconnect scenarios
• every new QR pairing attempt that ends in teardownQR → kill signal → restart

Each of these paths creates a new pool that is never closed. The old pool (and any connections it opened) is simply dropped, leaking idle connections into the auth Postgres database. In production this fills max_connections (default 100) within roughly an hour of normal instance create/delete/reconnect activity, with idle connections observed sitting for days/weeks. Symptom on the client side: pq: sorry, too many clients already, and QR pairing requests timing out (504) because the container never manages to connect.

Suggested fix

Cache the *sqlstore.Container on whatsmeowService (it already holds authDB *sql.DB as a struct field) and reuse it across StartClient/ReconnectClient calls instead of building a new one each time. At minimum, defer container.Close() (or close the previous container before replacing it) on every path that currently discards it without cleanup.

Repro

1. Create/delete a WhatsApp instance repeatedly (or force a few QR timeouts) against a Postgres-backed auth DB (POSTGRES_AUTH_DB set).
2. SELECT count(*) FROM pg_stat_activity; on the auth DB climbs steadily with state = 'idle' rows that never close.
3. Given enough cycles, max_connections is exhausted and pairing starts failing with pq: sorry, too many clients already.