fix(studio/pricing): long-context tier starts strictly above the threshold, not at it - #9527

The bug

calculate_cost flips a turn onto the long-context tier one token early:

# studio/backend/core/inference/pricing.py:246-254
lc_thresh = prices.get("long_context_threshold")
in_long_context_tier = (
    lc_thresh is not None
    and out["billable_input_tokens"] >= int(lc_thresh)   # <-- inclusive
    ...
)

OpenAI's own wording is strictly-above:

prompts with >272K input tokens are priced at 2x input and 1.5x output for the full session

— https://developers.openai.com/api/docs/models/gpt-5.4 (read 2026-08-22). The
tooltip on the pricing page this table cites in its header comment agrees:
≤272K input tokens for the standard column.

So a prompt of exactly 272,000 tokens is standard-rate at OpenAI, and
double-rate here. On gpt-5.5, 272,000 in / 1,000 out:

Two internal signals point the same way. The label this branch emits is
f"{model} (long-context >{lc_thresh})" — it already says >, on a request
that is not >. And test_openai_gpt55_short_context_under_272k_uses_base_rates
is named "under 272k" but only ever exercises 100k, so the naming convention in
the suite reads exclusive too.

Scope of the fix

All five long_context_threshold entries in pricing.py are OpenAI 272_000
(gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, gpt-5.5, gpt-5.4). There is
no Google or Anthropic threshold in that table, so >= → > is the complete
fix here with no counter-vendor to worry about. (Worth knowing for later: this
is not a safe global convention. xAI documents the opposite — "requests whose
prompt reaches the listed token threshold are billed at the higher rate for
all tokens in the request", https://docs.x.ai/docs/models — so if a non-OpenAI
threshold is ever added to this table it will need a per-entry flag rather than
another blanket comparison.)

About the test I changed

test_openai_long_context_threshold_boundary_inclusive asserted the current
behaviour with the comment # Threshold is inclusive (>=)., so this is not a
case of an untested edge — the convention was pinned deliberately. I've renamed
it to ..._exclusive, flipped it to 272,000 → standard / 272,001 → long-context,
and put the vendor quote in the comment so the next reader sees where the
convention comes from. If that inclusive reading was deliberate for a reason not
in the repo, say so and I'll close this — but the vendor sentence and the
(long-context >{n}) label both read the other way.

The cache-inflation test (250k + 50k cache_creation → 300,000 billable) is
unaffected; it stays comfortably above the line.

Verification

Ran studio/backend/tests/test_pricing.py (37 passed) and
studio/backend/tests/test_pricing_edge.py (24 passed; the 25th,
test_build_usage_chunk_forwards_anthropic_cache_creation_breakdown, imports
core.inference.external_provider, which I didn't have wired up locally — it
doesn't touch pricing).

271999  gpt-5.5                          $1.360 / $0.030
272000  gpt-5.5                          $1.360 / $0.030   <- was long-context
272001  gpt-5.5 (long-context >272000)   $2.720 / $0.045