fix(pi): remove PiModelPanel/PiThinkingLevelPanel

[Arnie97]

Keeps consistent with other coding agents, and use the ⚙️ settings button to switch between models and reasoning effort levels. Remove the pi-specific PiModelPanel and PiThinkingLevelPanel from the bottom toolbar, which overflows mobile screens and provides no real benefit.

Before	After

[github-actions]

Findings

• [Major] Pi model selection loses provider identity in the shared gear menu. Removing the Pi-only panel makes Pi sessions use the unified model list, but that list still keys and highlights rows by bare modelId; the repo explicitly preserves metadata.piSelectedModel because two providers can share the same model id. With duplicate IDs, React can reuse duplicate keys and the UI marks every matching modelId as selected, so users cannot tell which provider-backed model is active before changing it. Evidence: web/src/components/AssistantChat/HappyComposer.tsx:798, related context web/src/components/AssistantChat/HappyComposer.tsx:898 and web/src/components/AssistantChat/HappyComposer.tsx:911.
  Suggested fix:

  const isPiModelSelected = (piModel: PiModelSummary) => selectedPiModel
      ? selectedPiModel.provider === piModel.provider && selectedPiModel.modelId === piModel.modelId
      : model === piModel.modelId
  
  // inside group.models.map
  const selected = isPiModelSelected(piModel)
  key={`${piModel.provider}:${piModel.modelId}`}

Summary

• Review mode: initial
• One Major issue found: the new Pi path through the shared settings menu regresses provider-qualified model display for duplicate modelId entries.

Testing

• Not run (automation; static review only). Missing coverage: a web component test for Pi models with the same modelId under different providers should assert only the provider-qualified current model is selected.

HAPI Bot

[github-actions]

Findings

• No issues found.

Summary

• Review mode: follow-up after new commits
• The prior provider-qualified Pi model selection issue is addressed in the latest diff. Residual risk: no web component coverage found for the Pi gear menu with duplicate modelId values across providers or model-specific thinking-level filtering.

Testing

• Not run (automation: bun is not available on PATH in this environment).

HAPI Bot

[github-actions]

Findings

• [Major] Pi gear menu exposes bare model/effort controls before the Pi catalog is known — the deleted Pi toolbar buttons used piHasModels / selectedPiModel to block these controls until provider-qualified model data existed. After routing Pi through the unified gear menu, showModelSettings can still fall back to modelOptions while piModels is empty, so the menu can send a bare string/null model; Pi rejects string models when it cannot resolve a provider (cli/src/pi/runPi.ts:179, cli/src/pi/runPi.ts:217). The same state also shows unfiltered thinking levels before selectedPiModel is known. Evidence web/src/components/AssistantChat/HappyComposer.tsx:796.
  Suggested fix:

  const showModelSettings = Boolean(
      onModelChange
      && supportsModelChange(agentFlavor)
      && (agentFlavor === 'pi' ? Boolean(piModels?.length) : modelOptions.length > 0)
  )
  const piEffortHidden = agentFlavor === 'pi'
      ? !selectedPiModel || selectedPiModel.reasoning === false
      : false
  const showEffortSettings = Boolean(onEffortChange && supportsEffort(agentFlavor) && !piEffortHidden)

Questions

• None.

Summary

• Review mode: follow-up after new commits
• The provider-qualified selected-state fix is present, but the unified Pi settings menu still needs the old catalog/selected-model guards to avoid sending invalid Pi config during catalog load.

Testing

• Not run (automation). Suggested: add a composer/settings regression test for Pi with piModels=[] proving no model or thinking options are actionable until provider-qualified data exists.

HAPI Bot

[github-actions]

Findings

• [Major] Pi thinking-level controls are still actionable before a provider-qualified Pi model is known — the PR removes the dedicated PiThinkingLevelPanel, whose button was disabled when !selectedPiModel; the unified gear menu now includes showEffortSettings for Pi as soon as onEffortChange exists. In a loading/error/missing-catalog state, selectedPiModel is undefined, so the menu renders unfiltered default Pi levels and can send set_thinking_level without knowing whether the current model supports reasoning or that level. This reintroduces rejected/stale config risk on Pi (cli/src/pi/runPi.ts:234 waits for Pi confirmation and 409s on rejection). Evidence web/src/components/AssistantChat/HappyComposer.tsx:800.
  Suggested fix:

  const piEffortHidden = agentFlavor === 'pi'
      ? !selectedPiModel || selectedPiModel.reasoning === false
      : false
  const showEffortSettings = Boolean(onEffortChange && supportsEffort(agentFlavor) && !piEffortHidden)

Questions

• None.

Summary

• Review mode: follow-up after new commits
• The new commit fixed the Pi model-catalog fallback, but the Pi effort section still needs the old selected-model guard before the unified settings menu can replace the deleted Pi panel safely.

Testing

• Not run (automation). Suggested: add a composer/settings regression test for Pi with piModels=[] and/or piSelectedModel unresolved proving the effort section is hidden until selectedPiModel exists.

HAPI Bot

[github-actions]

[MAJOR] The unified settings menu is now the Pi path, but the Pi effort section is still shown whenever onEffortChange exists. The deleted Pi thinking button was disabled until a selectedPiModel existed; without that guard, Pi can show unfiltered default thinking levels while the catalog/selected model is unresolved and send a level the current model may reject.

Suggested fix:

const piEffortHidden = agentFlavor === 'pi'
    ? !selectedPiModel || selectedPiModel.reasoning === false
    : false
const showEffortSettings = Boolean(onEffortChange && supportsEffort(agentFlavor) && !piEffortHidden)