Omit offering tiers this environment cannot describe

[jfrench9]

/v1/offering advertised Large and XLarge in local dev as "Up to 0 subgraphs, 20 GB, 7-day retention" — plausible-looking numbers that were entirely fabricated.

Why it looked believable

Billing defines what is purchasable; graph.yml defines the specs. Where they disagree, the tier was listed anyway:

"max_subgraphs": tier_config.get("max_subgraphs", 0) if tier_config else 0,

That asserts "this tier has zero subgraphs" when the truth is "I have no config for it." Storage and retention then fell through to the Standard-shaped defaults in get_graph_limits / get_backup_limits.

Price and credits were correct throughout, because those come from billing/core.py, which has no environment dimension. That split — price right, every spec wrong — is what made the output convincing.

The fix is subtraction, not addition

The obvious move was to add Large/XLarge blocks to development. That would be fiction: dev runs a single graph_api, so those tiers cannot exist there, and the instance blocks would describe machines nothing will ever provision.

Instead, a tier with no config for the environment is now skipped. "Zero subgraphs, 20 GB" is a confident wrong answer where the truth is "not offered here" — omitting says that, and lets a client keep its own defaults rather than overwrite them with fabricated ones.

No schema change, so no SDK regen. Production is unaffected: all three tiers have configs and all three still list.

Also removes the now-dead if tier_config guards below the skip.

Pre-existing drift, deliberately left alone

The parity test surfaced that staging runs Large/XLarge at api_rate_multiplier 2.5/5.0 against production's 1.5/2.5. Not touched and excluded from the assertion — looser staging limits are plausibly intentional headroom for load testing, and that's a product call rather than something to normalize silently.

The test now allows a tier to be absent from an environment but requires that where it is present, its subgraph count and storage cap match production.

Testing

Full suite: 11,385 passed, just test-code clean. The only failures are the two pre-existing test_incremental_materialize cases that reproduce on main and pass in isolation.

Paired with robosystems-app, which guards the client side of the same bug — ?? falls back on null/undefined but not 0, so a fabricated zero overrode a correct fallback.