feat(catalog): wire metered billing through ProcessService

[tiagolupepic]

This commit introduces the metered items compute Fee in ProcessService

• Remove fixed-only filter from billing_segments scope to include metered
• Partition segments by product_type using PRODUCT_TYPES constants
• Add attach_fixed_fees and attach_metered_fees methods
• Call ChargeService for metered segments with pre-loaded filter targets
• Add specs for count/sum aggregations, graduated pricing, minimum amounts
• Add mixed fixed+metered segments spec

[lago-claude-ai-agent]

Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green

HOLD: Consolidated metered segments from different contracts can be billed with zero usage.

• build_invoice groups segments across contracts but resolves event filters using only the first contract. The resolver queries that contract's external ID, so ChargeService can bypass aggregation for another contract's segment. Resolve filters in each segment's contract context and add a regression spec with two consolidated metered contracts that both have usage.

[tiagolupepic]

build_invoice groups segments across contracts but resolves event filters using only the first contract. The resolver queries that contract's external ID, so ChargeService can bypass aggregation for another contract's segment. Resolve filters in each segment's contract context and add a regression spec with two consolidated metered contracts that both have usage.

Refactored the event filters to use the contract scope.

• Removed the contract from_billing_segments!.
• BillingSegmentsResolver is responsible to group by contract and define the boundaries (from_datetime / to_datetime) per contract
• Changed the queries of codes per contract (recurrence and not recurrence)
• Changed the target_key to use contract id scope. During the billing, the customer can have two different contracts (pricing) to the same product X. Using the previous target_key might create collisions because the timestamps will be put in the the same bucket and ChargeService will receive wrong data to filter

[lago-claude-ai-agent]

Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green

HOLD — metered segment processing now accepts configurations that the contract-backed charge path cannot execute.

• A valid recurring weighted_sum_agg reaches WeightedSumService#latest_value, which calls billing_context.previous_subscription_id?; Billing::Context raises NotImplementedError for contracts, rolling back the invoice group.
• Advance rate cards using latest_agg, max_agg, or weighted_sum_agg are also accepted by current validations, but AggregationFactory explicitly raises during finalization. Restrict unsupported configurations or implement contract-compatible behavior, and cover these cases in the process-service specs.

[tiagolupepic]

A valid recurring weighted_sum_agg reaches WeightedSumService#latest_value, which calls billing_context.previous_subscription_id?; Billing::Context raises NotImplementedError for contracts, rolling back the invoice group.
Advance rate cards using latest_agg, max_agg, or weighted_sum_agg are also accepted by current validations, but AggregationFactory explicitly raises during finalization. Restrict unsupported configurations or implement contract-compatible behavior, and cover these cases in the process-service specs.

Both options are going to be addressed soon in another ticket. It's part of Billing::Context

[lago-claude-ai-agent]

Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green

HOLD — the broadened pending scope processes valid metered configurations that this contract-backed fee path cannot safely finalize.

• ProcessService#pending_segments now includes advance metered cards, which are valid and due at the period start; it aggregates before usage exists and marks the segment done, while no contract pay-in-advance event path bills later usage. Exclude these cards or implement advance handling, with a regression spec.
• A valid recurring weighted-sum product reaches Billing::Context#previous_subscription_id? through WeightedSumService and raises NotImplementedError for the contract context. Support contract-backed recurring state or keep this configuration out of processing, and cover it.
• BillingSegmentsResolver flattens combinations from every contract and then matches each combination against every same-code target, so filter buckets and last-seen timestamps leak across contracts. Preserve contract identity during matching and strengthen the same-product multi-contract spec to assert per-contract values.

[lago-claude-ai-agent]

Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green

HOLD: Metered segment processing now incorrectly finalizes supported advance-billed cards at the segment start.

• pending_segments admits every metered segment, then compute_metered_fees uses the period-finalization path. Advance metered cards are modeled as per-event billing (and may be non-invoiceable/regrouped), but their segments are due at started_at; this can create a periodic invoice before usage exists and mark the segment done. Restrict this path to arrears metered cards until complete advance behavior exists, and add an advance-card regression spec.

[lago-claude-ai-agent]

Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green

HOLD — periodic processing now admits every arrears metered segment, but segment-backed recurring state is not implemented.

• Recurring weighted-sum products can raise when their aggregator calls the subscription-only previous_subscription_id? on a contract context, while recurring custom products restart without prior-period state because segment-backed cached aggregation persistence is explicitly skipped. Either support product/contract-keyed recurring state or exclude these configurations, and add periodic-processing regression coverage.