feat(billing): add invoice_item_types to LineItemDetails

[dashed]

This is for https://github.com/getsentry/getsentry/pull/20573

What

Adds a nested InvoiceItemTypes message to line_item_details.proto and attaches it to LineItemDetails as invoice_item_types (field number 2, previously unused).

message LineItemDetails {
  string uid = 1;
  InvoiceItemTypes invoice_item_types = 2;  // new
  string customer_facing_name = 3;
  string plural = 4;
  UnitInfo units = 5;
  BillableMetric billable_metric = 6;
}

message InvoiceItemTypes {
  optional string reserved  = 1;
  optional string ondemand  = 2;
  optional string activated = 3;
}

Why

A single SKU's reserved, on-demand, and activated usage can each settle as a distinct InvoiceItemType. Collocating those identifiers on the SKU's LineItemDetails lets getsentry declare them per SKU, instead of growing a shared enum every time a new SKU/context combination appears.

Each context is optional because not every SKU uses every context — some SKUs (e.g. Seer) fold their usage irregularly and only populate a subset.

Bindings

• Rust bindings regenerated (make build-rust) — the tracked .rs now contains InvoiceItemTypes and LineItemDetails.invoice_item_types.
• Python bindings regenerated (make build-py); the py/ output is gitignored and not part of this diff.
• Cargo.lock left at main's version (the build's version-bump drift was reverted).

Compatibility

Purely additive — a new message and a new field on a previously-unused field number. No existing fields change.

[github-actions]

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

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Jun 5, 2026, 9:59 PM

[volokluev]

according to the changelog, ondemand has been replaced with payg, can we keep this consistent?

[volokluev]

what is "activated usage"? what are the example values for it?

[volokluev]

what is a SKU? Have we defined it somewhere?

[volokluev]

it's not clear to me why we would need to expose this in the proto as anything but an enum. We already have the billable_metric, the customer_facing_name, why would we also need to add reserved_errors, reserved_trace_metric_bytes etc to the list? Why not just an enum of

enum InvoiceItemType {
    INVOICE_ITEM_TYPE_RESERVED = 1;
    INVOICE_ITEM_TYPE_PAYG = 2;
    INVOICE_ITEM_TYPE_ACTIVATED = 2;
}

I don't see why downstream services which need to generate a string like reserved_errors for their own purposes need that to be exposed in the lineitem proto