[web] Settings dropdowns render as OS-native option lists, breaking dark mode and design-system consistency

What version of Kimi Code is running?

0.29.1

Which open platform/subscription were you using?

kimi code web (managed login, kimi-for-coding)

Which model were you using?

Any — this is a UI issue (seen with K2.7 Coding)

What platform is your computer?

Windows 11 x64 (also reproducible in any browser, light and dark themes)

What issue are you seeing?

The settings dialogs and the KAP debug panel use native HTML <select> elements
(Settings → Agent → Default model, Settings → Archived → workspace filter,
provider manager → type, and the KAP debug panel filters). The closed control is
styled, but the opened option list is rendered by the OS/browser and ignores the
app's design system:

• In dark mode the option list stays a light, OS-styled popup.
• It shares none of the design-system surface / radius / shadow / hover tokens
  that the app's other popups (Menu/MenuItem) use, so it looks foreign next to
  them in both themes.

What steps can reproduce the bug?

1. Open kimi web and switch to the dark theme (Settings → appearance).
2. Open Settings → Agent and click the "Default model" select.
3. Observe the option list is a browser-native popup, not a design-system menu.
4. Same for Settings → Archived → workspace filter.

What is the expected behavior?

The open dropdown renders with the app's own tokens in both light and dark
themes — same surface, radius, shadow, hover wash, and accent check as the
existing Menu popups — and keeps the provider grouping of the default-model
select (introduced in #861).

Additional information

I'd like to submit a fix: replace the styled-native ui/Select.vue with a fully
custom listbox dropdown (trigger + fixed popup reusing the Menu surface and
MenuItem rows, option group headers, full keyboard navigation) and migrate all
native <select> call sites. Since the diff is larger than ~100 lines, I'm
waiting for maintainer feedback before opening the PR.

Start with ui/Select.vue and compare its behavior with the existing Menu and MenuItem popups. Identify the native select call sites named in the issue, including the default-model provider grouping introduced in #861, then verify the custom dropdown matches the stated light/dark tokens and supports full keyboard navigation across those uses.