[inputs.postgresql_extensible] incorrect version detection

### Relevant telegraf.conf

```toml
[[inputs.postgresql_extensible]]
alias = "db-instance-1"
# primary
address = "postgres://postgres:PW@1.1.1.1/db?default_transaction_read_only=on&application_name=telegraf-pgexport"
tagexclude = ["server"]
fieldexclude = ["datname"]

[[inputs.postgresql_extensible.query]]
measurement = "pg_stat_user_tables"
script = "/etc/telegraf/query_pg_stat_user_tables_max1400.sql"
tagvalue = "schemaname,relname"
max_version = 1400
```

### Logs from Telegraf

```text
2026-02-24T04:30:08.738Z | 2026-02-24T04:30:08Z E! [inputs.postgresql_extensible::db-instance-1] Error in plugin: ERROR: column p.num_dead_tuples does not exist (SQLSTATE 42703)
```

### System info

Telegraf 1.37

### Docker

_No response_

### Steps to reproduce

1. Have variant of pg query with max_version < X
2. configure plugin to query DB with version >= X
3. make idle connection disrupted (idk how, just theorising what might be happening)
4. on next Gather() version check silently fails, setting `dbVersion = 0` and therefore using wrong version of the query on it.

### Expected behavior

telegraf should assess health of connection before reusing it on first Gather()

### Actual behavior

symptoms point that telegraf intermittently fail version check and use wrong version of a query. We see intermitted errors like those given in example with no apparent pattern:

- no regularity
- different database

Only common factor is that all reported errors are schema related and come from queries which are DB version constrained.

### Additional info

I think easiest option is to switch from `database/sql` pool to `pgxpool` . pgxpool [checks](https://github.com/jackc/pgx/blob/v5.8.0/pgxpool/pool.go#L630) health of connection using ping if connection was idle for more than second. This will detect if connection was disrupted and force fresh connection to run version check and all subsequent queries on.

Start at the inputs.postgresql_extensible plugin's Gather() path and inspect how database/sql connection reuse, version checks, and dbVersion are handled after an idle connection is disrupted. Compare the reported behavior with the pgxpool health-check reference linked in the issue. Done means a failed or stale connection cannot silently leave dbVersion at 0 and cause a version-constrained query to run against the wrong PostgreSQL version.

Written by the indexing model from the issue text.