fix(billing-platform): Replace reserved_rate with reserved_pricing

[brendanhsentry]

reserved_rate originally covered two different concepts: package-specific reserved tiers (ex 50k errors, 100k errors, 1M errors, etc.) and a per-unit rate for shared pool line items (ex legacy Seer). Those cases accept different inputs, reserved volume versus usage respectively, so separating them into distinct fields makes their meaning explicit and makes it easier for downstream services to interpret them correctly.

[github-actions]

The latest Buf updates on your PR. Results from workflow ci / buf-checks (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	⏩ skipped	✅ passed	✅ passed	Apr 21, 2026, 7:04 PM

[volokluev]

I'm not sure I understand the rationale. Maybe what would be helpful is some example tests showing how this captures a case that could not have been captured otherwise. Here is the crux of what I don't understand:

Those cases accept different inputs, reserved volume versus usage respectively

Why are those things different? Here's what I understand:

1. The reserved_rate captures the pricing rate for reservations of lineitems
2. If I have a shared pool, the platform would use the usage data and act as if the customer had reserved as much as they used (up to the shared pool limit).

Am I incorrectly assuming something?
How does your interface change simplify this flow?

[brendanhsentry]

@volokluev Everything you described is correct. This change is not necessary for the UsagePricer and Invoice services to work properly.

Both cases can be represented as “tiers”, but downstream services have to interpret them differently. In one case the tiers are a pricing rate applied to usage; in the other they are fixed reservation choices keyed by reserved volume.

The goal of the interface change is to split the representation so the intended interpretation is more explicit. This allows us to avoid passing unnecessary information to the UsagePricer for line items where reserved_rate doesn't rely on usage to calculate prices.

[volokluev]

@brendanhsentry can you show me an example (maybe with pseudocode) that explains what this contract change makes more explicit?