feat(ui): scaffold packages/ui with theme foundations

[EhabY]

🤖 This PR was created by Coder Agents on behalf of @EhabY.

Closes DEVEX-624.

Scaffolds the shared component library for the Workspaces webview work. Foundations only, no components yet (DEVEX-618/619/620 build on this).

• packages/ui: React + TS package wired like existing packages and consumed as source like webview-shared, but shaped for a future standalone NPM split: exports map (., ./tokens.css, ./codicon.css), react as the only peer dependency, @vscode/codicons (asset-only) as the only runtime dependency, no workspace:* deps. A short README documents the theming model and the rules that keep the package splittable.
• tokens.css: semantic --ui-* tokens mapped to --vscode-* variables, the single place the library is theme-matched to VS Code. Every token always resolves: variables VS Code may omit (hover/selection fills in high contrast themes, contrast borders outside them) declare fallbacks that match native behavior.
• useVscodeTheme: returns the active theme kind from the data-vscode-theme-kind body attribute VS Code maintains in webviews, synced via MutationObserver + useSyncExternalStore.
• Storybook: the theme switcher now covers all four theme kinds (Light, Dark, High Contrast, High Contrast Light) and the decorator mirrors data-vscode-theme-kind on the body. Theme data is no longer vendored: all four themes import from @vscode-elements/webview-playground, deleting the two ~700-line copied theme files. Net, the PR removes ~1,500 lines.
• UI/Foundations story: enumerates every --ui-* token from the loaded stylesheets (cannot drift from tokens.css) and renders each as a swatch with its resolved value. Chromatic modes snapshot it in all four themes, scoped to this story to keep snapshot counts down.

Testing

• test/webview/ui/useVscodeTheme.test.ts: theme-kind mapping, missing-attribute default, re-render on theme change.
• Story rendered headlessly against the production Storybook build in all four themes; all 16 tokens resolve to expected values and fallbacks engage where variables are absent.
• pnpm typecheck, lint, format:check, test, build, and storybook:ci all pass.

Note: webview-playground 1.9.0 carries newer VS Code theme captures than the previously vendored copy, so existing Chromatic baselines will show a one-time diff.

Implementation decisions

1. Build: source-consumed like webview-shared (no vite build), but self-contained so a real build step can be added at the actual NPM split.
2. Codicon export: ./codicon.css added now since follow-up issues will use it.
3. Semantic token layer (vs raw --vscode-* per component, as vscode-elements does): the deprecated @vscode/webview-ui-toolkit validated the token-layer pattern with a JS design-token system; a pure-CSS layer gets the same single theming point without the machinery, and gives the future standalone package one place to define non-webview fallbacks.
4. No sideEffects field: with it, this Vite/rolldown pipeline tree-shook the storybook.preview.ts to tokens.css chain out of the production Storybook build (even with **/*.css). Dev mode masked it. Dropped as speculative; revisit at the actual split.
5. Radix: deferred to DEVEX-619, which explicitly scopes adding the only Radix runtime deps.
6. Theme data from npm: @vscode-elements/webview-playground publishes the exact theme modules the repo had copied by hand. Importing them (typed via a small wildcard .d.ts) deletes the vendored data and makes theme refreshes a pnpm update.
7. No webview-shared re-export of useVscodeTheme: no consumers exist yet and it would add a workspace dep.

[linear-code]

DEVEX-624