[vscode-ext-webview-fluentui] Derive high-contrast themes and remaining neutral tokens from the active VS Code theme

Enhancement

Two parts of @microsoft/vscode-ext-webview-fluentui still return fixed Fluent colors instead of deriving from the user's active VS Code theme. Both are visible to consumers that adopt the theming layer, and both are better solved in the package than worked around downstream.

1. High-contrast kinds are not adaptive

createVSCodeFluentTheme derives a theme for vscode-light and vscode-dark, but returns static Teams themes for both high-contrast kinds (dist/theme/core/createVSCodeFluentTheme.js in 1.1.0):

case 'vscode-high-contrast':
    return teamsHighContrastTheme;
case 'vscode-high-contrast-light':
    // TODO: find a better theme for this
    return teamsLightTheme;

teamsLightTheme for HC Light is the weaker of the two: it is not a high-contrast theme at all, so under a light high-contrast workbench the Fluent surface silently drops to normal-contrast colors while Monaco (which does map vscode-high-contrast-light → hc-light) does not. The two engines disagree on exactly the theme kind where contrast matters most.

This is a carried-over limitation rather than a regression — the same // TODO: find a better theme for this existed in the Cosmos DB extension's local theme engine before it was replaced by this package — but centralizing the theming is the right moment to fix it once for every consumer.

2. Some global neutral tokens remain fixed

The generator remaps colorNeutralForeground1/2/3, their hover/pressed/selected variants, colorNeutralForegroundDisabled, and colorNeutralStroke1/2/3 + colorNeutralStrokeDisabled. colorNeutralForeground4 is not remapped.

That token is not obscure: it is the conventional Fluent choice for secondary/metadata text, and the Cosmos DB extension uses it for query-result tree and table text in ResultTabViewTree.tsx and ResultTabViewTable.tsx. Under a community theme it stays a fixed Fluent gray while every neighbouring token tracks the workbench.

Worth auditing the full neutral foreground/stroke set for other gaps at the same time, rather than adding colorNeutralForeground4 alone.

Proposal

• Derive both high-contrast kinds from the live VS Code theme, the same way light and dark are derived, rather than returning a static Fluent theme. If full derivation is not practical for HC, at minimum stop returning a normal-contrast theme for vscode-high-contrast-light.
• Extend the neutral remapping to cover colorNeutralForeground4 and any other tokens the audit surfaces.
• Keep createVSCodeFluentTheme's existing contract: snapshot factory, undefined for an unrecognised kind, no new observer or Monaco dependency.

Acceptance criteria

• Automated contrast assertions for both high-contrast kinds, not just visual inspection — HC Light in particular should be caught by a test rather than by a reviewer.
• Interaction-state coverage: rest, hover, pressed, selected, disabled and focus must stay visually distinct after the remapping.
• Verify Fluent and Monaco resolve a consistent surface under each of the four theme kinds.
• No change in behaviour for light and dark beyond the newly mapped tokens.

Context

Filed from the Cosmos DB extension's adoption of 1.1.0 (microsoft/vscode-cosmosdb), which replaces its local theme engine with this package for Fluent and Monaco theming. The adoption deliberately does not patch these two gaps locally — a local override would re-fork the theme engine we just removed. Related but distinct: #925.

---

Separate, unrelated: published sourcemaps reference missing sources

Filed here to avoid losing it; happy to split into its own issue.

Every dist/**/*.js.map in 1.1.0 points at sources that are not published. package.json ships only dist, README.md, CHANGELOG.md and LICENSE, while e.g. dist/index.js.map has "sources":["../src/index.ts"] and no sourcesContent.

Consumers that inline the package see warnings for every file. In vscode-cosmosdb this is a wall of Sourcemap ... points to missing source files on every Vitest run that touches the package.

Fix is either "sourcesContent" embedded in the emitted maps ("inlineSources": true in tsconfig) or adding src to files. The former keeps the tarball closer to its current size.

Start with createVSCodeFluentTheme and its handling of the four VS Code theme kinds, then inspect the neutral-token mappings and the consumers named in ResultTabViewTree.tsx and ResultTabViewTable.tsx. Add automated contrast and interaction-state coverage for high-contrast themes and verify Monaco and Fluent surfaces agree without changing light or dark behavior. Treat the separate dist/**/*.js.map sourcemap issue as unrelated work.