feat(events-processor): run catalog events as a separate pipeline

[rsempe]

Context

An alternative to #819 and #826, which ran the catalog consumer inside the subscription processor. This version keeps the two flows apart: a catalog failure, backlog or memory spike can't hold back subscription events, and each flow can be scaled, deployed and eventually retired on its own.

Description

• Shared building blocks (first commit, no behaviour change): the record loop with its retry and dead-letter rules, the billable metric enrichment, and the producers move to processors/pipeline. The events processor uses them as is.
• Catalog pipeline: LAGO_EVENTS_PROCESSOR_PIPELINE=catalog_events runs processors/catalog_processor instead of the events processor, in a separate deployment from the same image.
  • It consumes only LAGO_KAFKA_CATALOG_RAW_EVENTS_TOPIC.
  • It resolves the contract serving each event and writes the event to LAGO_KAFKA_CATALOG_ENRICHED_EVENTS_TOPIC.
  • It sends the event to be priced in advance when a contract rate card bills its metric in advance.
  • The default events pipeline is unchanged.
• Cache per pipeline: the catalog pipeline loads billable metrics, contracts, contract rate cards, rate cards and products; the events pipeline keeps its current tables. Debezium now publishes the catalog tables.
• Dev stack: catalog-events-processor runs under the catalog profile.

Open points:

• Advance pricing: catalog events are still sent to the subscription charged-in-advance topic, with the contract's external id in external_subscription_id. A dedicated topic would need a new API consumer.
• Deployment: the Helm chart and lago-deploy need a second processor deployment with the catalog variables.
• Debezium: with LAGO_USE_MEMORY_CACHE, the production connector must publish contracts, contract_rate_cards, rate_cards and products. extra/debezium_config.json only covers the dev stack. Without them, the catalog cache loads its snapshot and then never updates.