feat(billing): add effective retention endpoint

[dashed]

Stacks on #370. Adds the endpoint proto for the platform effective-retention resolver (Alternative D, stage B4) — the read side that will resolve package defaults + contract overrides into concrete effective retention.

New services/quotas/v1/endpoint_get_retentions.proto (no service declaration, mirroring endpoint_get_quotas.proto):

message GetRetentionsRequest { uint64 organization_id = 1; }

message EffectiveRetentionSettings {
  uint32 standard_days = 1;              // always positive
  optional uint32 downsampled_days = 2;  // present iff the category has a distinct downsampled repr
}
message EffectiveDataCategoryRetention {
  DataCategory category = 1;             // billing proto category
  EffectiveRetentionSettings settings = 2;
}
message GetRetentionsResponse {
  repeated EffectiveDataCategoryRetention retentions = 1;
  bool contract_present = 2;             // false => no platform contract, fall back to legacy
  string retention_policy_revision = 3;  // opaque; empty when no override
  uint32 event_retention_days = 4;               // category-less standard (legacy compat)
  uint32 downsampled_event_retention_days = 5;   // category-less downsampled (legacy compat)
}

Key distinction from the raw retention messages (#368/#370): EffectiveRetentionSettings carries concrete days with no inheritance sentinel — the resolver normalizes inherit_standard to concrete standard days, so the effective endpoint never exposes the raw sentinel. downsampled_days is absent (not zero) for standard-only categories.

The resolver that populates this is the follow-up GetSentry PR. Python and Rust round-trip coverage.

[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	Jul 18, 2026, 12:27 PM