Fix provider-specific effort and service-tier UI

[1jehuang]

Summary

• keep named OpenAI-compatible models to one picker row and use /effort for effort selection
• only render the OpenAI [fast] service-tier badge for OpenAI providers
• add regressions for Z.AI picker rows and DeepSeek badge rendering

Verification

• cargo test -p jcode-tui --lib route_effort_support_covers_effort_capable_runtimes_only
• cargo test -p jcode-tui --lib non_openai_provider_hides_openai_service_tier
• cargo test -p jcode-tui --lib model_widget_and_overview_show_same_runtime_metadata

Fixes #742. Fixes #739.

--- — Jcode agent (automated triage), on behalf of @1jehuang

[greptile-apps]

Greptile Summary

This PR updates provider-specific effort and service-tier UI behavior. The main changes are:

• Keeps OpenAI-compatible model routes to one picker row instead of expanding them by effort.
• Uses /effort as the path for OpenAI-compatible effort selection.
• Shows the OpenAI service-tier badge only when provider metadata is classified as OpenAI.
• Adds regression tests for Z.AI picker rows and non-OpenAI service-tier badge rendering.

Confidence Score: 4/5

This PR has one contained UI bug to fix before merging.

The effort-route change is localized and covered by updated tests. The service-tier badge predicate still classifies generic OpenAI-compatible runtimes as OpenAI, so custom compatible endpoints can display incorrect UI state.

Files Needing Attention: crates/jcode-tui/src/tui/info_widget_model.rs

T-Rex Logs

What T-Rex did

• I added a narrow Rust unit test that sets InfoWidgetData.provider_name to OpenAI-compatible and service_tier to priority, then exercises the render_model_widget and render_model_info paths.
• I ran the targeted regression test and observed that both render_model_widget and render_model_info first lines contained [fast], causing the regression assertion to fail.
• I captured and uploaded artifacts documenting the reproduction, including the regression test patch, the verbose cargo test output showing the [fast] renders, and the exact cargo test command used.
• I reviewed the verification log and confirmed that per-command EXIT_CODE:0 markers were present and workspace warnings did not fail verification.

_{Ran code and verified through T-Rex}

Important Files Changed

Filename	Overview
crates/jcode-tui/src/tui/app/inline_interactive.rs	Updates the route-effort regression test to assert OpenAI-compatible profile routes are not expanded into effort picker rows.
crates/jcode-tui/src/tui/app/inline_interactive_placeholder_routes.rs	Changes effort-row support so OpenAI-compatible routes remain single picker rows and directs effort changes through the separate effort flow.
crates/jcode-tui/src/tui/info_widget_model.rs	Adds provider-gated service-tier rendering and tests, but the OpenAI prefix check still includes generic OpenAI-compatible runtimes.

Sequence Diagram

sequenceDiagram
participant Catalog as Model catalog route
participant Picker as Inline model picker
participant Info as Info widget metadata
participant UI as TUI display

Catalog->>Picker: route.api_method
Picker->>Picker: route_supports_reasoning_effort(api_method)
alt effort-capable native route
    Picker->>UI: render model rows per supported effort
else OpenAI-compatible or unsupported route
    Picker->>UI: render one plain model row
end
Info->>Info: provider_name + service_tier
alt provider classified as OpenAI
    Info->>UI: append [fast]/[flex] service-tier badge
else non-OpenAI provider
    Info->>UI: hide OpenAI service-tier badge
end

Loading

Prompt To Fix All With AI

### Issue 1
crates/jcode-tui/src/tui/info_widget_model.rs:337-341
**Generic compatible badge leaks**
`starts_with("openai")` still treats the generic `OpenAI-compatible` runtime label as OpenAI. `runtime_display_name()` returns exactly `OpenAI-compatible` for custom compatible endpoints, so those non-OpenAI providers continue to show `[fast]` whenever `service_tier` is `priority`.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix: scope fast badge to OpenAI provider..." | Re-trigger Greptile}

[greptile-apps]

Generic compatible badge leaks
starts_with("openai") still treats the generic OpenAI-compatible runtime label as OpenAI. runtime_display_name() returns exactly OpenAI-compatible for custom compatible endpoints, so those non-OpenAI providers continue to show [fast] whenever service_tier is priority.

Context Used: AGENTS.md (source)

Artifacts

Repro: generated Rust regression test patch for OpenAI-compatible provider badge rendering

• Evidence file captured while the check ran.

Repro: verbose cargo test output showing OpenAI-compatible renders [fast] and fails the regression assertion

• The full command output behind this check.

Repro: exact cargo test command used for the narrow badge leak check

• Evidence file captured while the check ran.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/jcode-tui/src/tui/info_widget_model.rs
Line: 337-341

Comment:
**Generic compatible badge leaks**
`starts_with("openai")` still treats the generic `OpenAI-compatible` runtime label as OpenAI. `runtime_display_name()` returns exactly `OpenAI-compatible` for custom compatible endpoints, so those non-OpenAI providers continue to show `[fast]` whenever `service_tier` is `priority`.

**Context Used:** AGENTS.md ([source](https://app.greptile.com/solo-systems/github/1jehuang/jcode/-/custom-context?memory=04aa75db-3e8e-4529-8341-c7b9dc373978))

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.