feat(api: Improve deletion semantics for endpoints

[iambriccardo]

Summary

Improve deletion behavior across the ETL API so destructive endpoints behave more predictably when pipelines are still active, and so source-side ETL state is cleaned up more deliberately during pipeline and tenant teardown.

What changed

• Added active-pipeline guards to deletion endpoints so they return 409 Conflict instead of attempting deletes while a replicator is still active in Kubernetes.
• Refactored pipeline deletion into smaller helpers that separate API-side cleanup, source-side ETL state removal, and replication slot deletion.
• Updated source and destination delete endpoints to surface clearer conflict behavior when they are still referenced by pipelines.
• Extended tenant deletion to clean source-side ETL state per source before deleting the tenant row in the API database.
• Added Kubernetes helpers for determining whether a replicator should be treated as active for deletion guards.
• Made replication slot deletion a no-op when there are no slots to remove.

Behavior changes

• DELETE /pipelines/{id} now rejects deletion for active pipelines.
• DELETE /destinations/{destination_id}/pipelines/{pipeline_id} now rejects deletion for active pipelines.
• DELETE /sources/{id} and DELETE /destinations/{id} now return conflicts when the resource is still in use by pipelines.
• DELETE /tenants/{tenant_id} now performs best-effort source cleanup first, then deletes the tenant row and lets Postgres cascade the tenant-owned API rows.
• If a source database is already unreachable during tenant deletion, the request now logs the failure, skips source-side cleanup for that source, and still removes the tenant from the API database.

Tests

• Updated deletion tests for pipelines, destinations, sources, and tenants to cover active vs. inactive pipeline behavior.
• Added coverage for tenant/source uninstall paths, unreachable-source tenant deletion, and missing-ETL-table scenarios.
• Added a Kubernetes unit test to ensure failed pods are treated as active for deletion guards.

Notes

This PR is primarily about deletion semantics and cleanup behavior. Most of the code churn is in route-level orchestration, shared deletion helpers, and the corresponding test coverage.

[coveralls]

coverage: 78.197% (-0.05%) from 78.248% — new-reset-endpoint into main

[farazdagi]

Thank you for looking into commented items. lgtm!