Replace update-catalog with validation gate and PR-based flow

[bhillkeyfactor]

The existing update-catalog.yml committed catalog entries directly to the integrations-catalog main branch with no validation, no PR, and no review. Several bugs accumulated:

• *-dev / *-test / *-staging / *-poc repos with update_catalog=true leaked entries into the public catalog (~6 known leaks were manually deleted Feb-Mar 2026).
• Repos with empty names, missing descriptions, or invalid integration_type values published verbatim — no schema check.
• Private repos with link_github=true created broken-link entries on the public catalog. There was no notion of a Coming Soon entry for intentionally-private in-flight integrations.
• Every catalog write used the same "Added the manifest for X" commit message regardless of whether it was an add or an update.

This replacement adds three things:

1. A validation gate that runs before rendering. Rejects repo names matching the non-production pattern (failsafe — primary control is still update_catalog=false in the manifest), verifies required fields exist (name, integration_type, description), validates integration_type against an enum, and handles the private/link_github combinations correctly (private + link_github=false renders as Coming Soon; private + link_github=true is rejected with a clear error).

2. A branch + PR flow instead of direct-to-main commits. Each integration push lands on a catalog-update/{repo} branch and opens a PR labeled catalog-add, catalog-update, or coming-soon depending on the entry type. Re-pushes force-update the branch and the existing PR in place (no duplicates).

3. Idempotent gh label create calls before gh pr create. Without these, the first run with a fresh integrations-catalog repo fails at the PR-creation step because the labels don't exist yet (same failure mode the cleanup-catalog workflow hit during its initial deployment).

Additions vs. the draft in integrations-catalog/docs/proposed-update-catalog.yml:

• dns-plugin added to ALLOWED_TYPES (a category page now exists in the catalog repo and an integration of this type has already published).
• The label-create block (point 3 above), informed by the cleanup workflow's own first-run failure.

Aggressive rollout: this replaces the unversioned reference that every integration repo's caller workflow points at. The next push from any integration repo will use the new flow. The flow fails closed — if validation rejects, no catalog entry is added; the catalog repo's main branch is unaffected.