fix: limit pg_stat_statements queryid cardinality to prevent VictoriaMetrics OOM

Add ORDER BY calls DESC LIMIT 100 to both pg_stat_statements metric SQL
variants (PG 11+ and PG 17+) so pgwatch only exports the top 100 most-called
queries. Previously ALL queryids were exported — on PostgREST databases this
meant ~7K new unique queryids per minute, creating 16M+ time series that
OOM-killed VictoriaMetrics (3.9GB/4GB).

Also add sample_limit: 5000 to the pgwatch scrape config as a safety net
to reject any scrape that produces more than 5000 samples.

Closes #143
Related to #130

https://claude.ai/code/session_01SzJxzZNQjDQphaHyaX3RU7

Author: claude

config/pgwatch-prometheus/metrics.yml

@@ -1035,6 +1035,8 @@ metrics:
           temp_bytes_read::int8 as temp_bytes_read,
           temp_bytes_written::int8 as temp_bytes_written
           from aggregated_statements
+          order by calls desc
+          limit 100
       17: |
         with aggregated_statements as ( /* pgwatch_generated */
           select
@@ -1081,6 +1083,8 @@ metrics:
           temp_bytes_read::int8 as temp_bytes_read,
           temp_bytes_written::int8 as temp_bytes_written
           from aggregated_statements
+          order by calls desc
+          limit 100
     gauges:
       - calls
       - plans_total

config/prometheus/prometheus.yml

@@ -15,6 +15,7 @@ scrape_configs:
     scrape_interval: 30s      # How often to scrape PGWatch
     scrape_timeout: 25s       # Timeout for each scrape (must be < scrape_interval)
     metrics_path: /pgwatch
+    sample_limit: 5000        # Safety net: reject scrapes with >5000 samples to prevent cardinality explosion
 
   # Self-monitoring: Victoria Metrics internal metrics
   - job_name: 'victoriametrics'