[+] implement admin.drop_source_partitions for proactive decommission cleanup

[RafayKhattak]

Closes #1340

When you decommission a monitored database, its metric data stays behind in the
partitions until retention kicks in. If retention is set to something like 90 days,
that's a lot of dead data sitting around. The only other option right now is manually
hunting down and dropping the partition tables yourself, which is tedious because
a single source can have dozens of partitions scattered across every metric.

This adds a single function you can call:

SELECT admin.drop_source_partitions('my_old_db');

It finds all Level-2 (dbname) partitions belonging to that source by reading the
partition bound expressions from pg_catalog, so it works correctly even when the
table name uses the MD5 hash fallback for long database names. For each one it
acquires the same advisory lock used by ensure_partition_metric_dbname_time,
detaches and drops the partition (which cascades to all the time sub-partitions),
then cleans up admin.all_distinct_dbname_metrics so the source disappears from
Grafana dropdowns.

The function is idempotent, calling it twice or for a source that doesn't exist
just returns 0.

Changes

• New file: internal/sinks/sql/drop_source_partitions.sql
• Modified: internal/sinks/postgres.go (embed + add to schema init slice)

Testing

Tested against a live multi-tenant Docker environment with both normal-length and
63+ character database names (MD5 hash path).