inventory: POSTGRES_SSL_MODE defaults to disable, exposing unfixable lib/pq vulnerabilities

## Summary

The inventory components connect to PostgreSQL in plaintext by default, which is
the precondition an attacker needs for five currently-unfixable `github.com/lib/pq`
vulnerabilities.

`deploy/inventory/common/02-config.yaml.tmpl:12`

```yaml
POSTGRES_SSL_MODE: "{{ default "disable" .SSLMode }}"
```

All three binaries read that value straight into `pq.Config.SSLMode`
(`cmd/inventory/inventory-{aggregator,viewer,inspector}/main.go`), so unless an
operator overrides `.SSLMode`, the connection is unauthenticated and unencrypted.

## Why it matters now

Seven advisories against `github.com/lib/pq` were published on 2026-08-18. All are
*all versions affected, no known fix*; `v1.12.3` is already the latest release.
Five of them are triggered by what the **server** sends, so an on-path attacker
between the pods and PostgreSQL can trigger them directly when TLS is off:

| ID | Summary | Applies |
|---|---|---|
| [GO-2026-6168](https://pkg.go.dev/vuln/GO-2026-6168) | Unbounded SCRAM iteration count causes CPU denial of service | yes |
| [GO-2026-6170](https://pkg.go.dev/vuln/GO-2026-6170) | Malformed backend frame length causes panic | yes |
| [GO-2026-6171](https://pkg.go.dev/vuln/GO-2026-6171) | Malformed RowDescription and DataRow messages cause panics | yes |
| [GO-2026-6172](https://pkg.go.dev/vuln/GO-2026-6172) | Backend frame lengths cause pre-validation memory exhaustion | yes |
| [GO-2026-6173](https://pkg.go.dev/vuln/GO-2026-6173) | Pre-protocol error reader permits unbounded memory consumption | yes |
| [GO-2026-6166](https://pkg.go.dev/vuln/GO-2026-6166) | GSS authentication completes without mutual proof | no, GSS is never configured |
| [GO-2026-6169](https://pkg.go.dev/vuln/GO-2026-6169) | Disclosure of wrong `.pgpass` credential via `hostaddr` | no, `pq.Config` is built purely from env vars |

Impact is denial of service against `inventory-aggregator`, `inventory-viewer` and
`inventory-inspector` (panic or memory exhaustion), not data compromise. Setting
`POSTGRES_SSL_MODE` to `require` or `verify-full` removes the on-path variant
today; it does not help against a compromised PostgreSQL server itself.

Note that `verify-full` is the only value that authenticates the server. `require`
encrypts but does not verify the certificate, so it does not stop an active
attacker who can present one.

## Options

1. **Change the template default** to `require` or `verify-full`. One line, but it
breaks any existing deployment whose PostgreSQL has no TLS configured, so it
needs a release note and probably a deprecation window.
2. **Migrate off `lib/pq`.** `jackc/pgx` is the maintained alternative. The surface
is small and mechanical: `pq.Config`, `pq.NewConnectorConfig`, `pq.SSLMode*` and
one `pq.Array`, across 8 files under `internal/inventory` and `cmd/inventory`.
This is the only option that addresses a hostile or compromised server rather
than just an on-path one.
3. **Accept**, and document that operators are expected to set
`POSTGRES_SSL_MODE` themselves.

## Note on CI

These no longer block CI. #630 changed `make vulncheck` to fail only on
vulnerabilities that have a published fix, so all seven are reported on every run
and allowed through. That is deliberate, and it is exactly why this issue exists:
nothing will force the decision, so it needs an owner.

Start at deploy/inventory/common/02-config.yaml.tmpl:12 and trace the value through cmd/inventory/inventory-{aggregator,viewer,inspector}/main.go; the issue also identifies eight migration files under internal/inventory and cmd/inventory. Review the three listed options and their deployment impact first. Done requires an owner-selected approach with its affected files and release-note or compatibility needs resolved.

Written by the indexing model from the issue text.