feat: add reusable JSON-driven option picker

[pi-claw-agent]

Summary

Added a reusable webview option picker component (openStatusPicker) with JSON-driven options (icon/label/description/selected), fuzzy token search, keyboard navigation, viewport-clamped four-corner anchoring, and height/width caps with scrolling and ellipsis. The model, thinkingLevel, effort, and contextBudget bottom-bar pickers now request JSON option payloads from the host (PiService buildStatusPickerOptions / applyStatusPickerOption) and open this picker anchored above the clicked status item instead of VS Code's native QuickPick; slash-command entry points keep the native picker as a fallback. Protocol schemas and focused tests cover filtering, placement clamping, static option builders, and end-to-end wiring.

Validation

• bun install --frozen-lockfile
• bun run check-types
• bun run lint
• bun run compile-tests
• bun esbuild.js
• bun esbuild.webview.js
• xvfb-run -a bun x vscode-test (204 passing)
• git diff --check

Closes #79

[pi-claw-agent]

Independent Agent review: approved

Review round 1/2 for bd780489b5a4.

A reusable JSON-driven option picker (openStatusPicker) covers the requested capability set — data-driven icon/label/description/selected items, four-corner viewport-clamped anchoring, fuzzy token search, keyboard/pointer interaction, and height/width caps with list scrolling and ellipsis — and the model, thinking, effort, and context-budget status-bar pickers now use it via a request/apply protocol while slash-command paths keep the native picker. Pure helpers (filtering, clamping, static option builders) and wiring are covered by focused tests, and all validation passes.

Findings

• minor: Picker total height can exceed the 400px value used for placement — src/webview/components/option-picker.ts:30
  • Evidence: measure() caps the panel at MAX_HEIGHT 400, but CSS caps only the inner list (.option-picker-list max-height: min(60vh, 340px)); title + input + list + padding can total roughly 430px. resolvePickerPlacement therefore reserves 400px, so with a tall list a bottom-corner anchor (bottomLeft/bottomRight) near the lower edge positions the panel ~30px past the viewport bottom, and the overall component is not height-capped as the issue requires ("选择器不要溢出屏幕", height cap). Current integrations all use topRight anchored above the bottom status bar, where the real panel bottom still lands within the viewport, so this is latent rather than observable today.
  • Recommended fix: Cap the panel itself (e.g. max-height on .option-picker with the list flex-shrinking to scroll) so measured height always equals actual height, then place against the real capped size; add a placement test with a >400px content height.

Reviewer checks

• Inspected git diff main...bd78048 and traced the status-bar click flow, host option builders/apply paths, protocol schemas, placement math, CSS caps, and the retained native fallbacks.
• bun run compile-tests
• ./node_modules/.bin/mocha --ui tdd out/test/option-picker-helpers.test.js (6 passing)
• ./node_modules/.bin/eslint src/test/option-picker-helpers.test.ts
• bun run check-types
• bun esbuild.webview.js
• git diff --check main...bd78048

Generated by the independent sandboxed Reviewer Agent. The PR still requires human review and merge.