Support portable icons for session configuration options

Start with schema/state.schema.json and schema/commands.schema.json, focusing on Icon, SessionConfigPropertySchema, and SessionConfigValueItem. Review the existing icon guidance and schema tests before deciding how static and dynamic options should align. Done means the representation, fallback and accessibility behavior are documented, with examples and tests covering both option forms.

Problem

AHP lets hosts describe session configuration choices without requiring clients to know provider-specific property names or values:

• ConfigPropertySchema / SessionConfigPropertySchema provide enum, enumLabels, and enumDescriptions.
• SessionConfigValueItem provides value, label, and an optional description for dynamic completions.

Neither representation currently carries an option icon or a standardized icon hint. AHP already defines an Icon type, but it is not exposed on configuration options.

This leaves generic clients with a choice between text-only options and client-maintained mappings for recognized properties/values. Approval-related settings are one example: a client should not guess an option's meaning from an unfamiliar host-defined string just to choose an icon.

Request

Define an optional, client-independent way to describe per-option icons or semantic presentation hints for session configuration choices.

The convention should:

• Cover both static enum options and dynamic sessionConfigCompletions items consistently.
• Avoid requiring VS Code Codicon identifiers or another client's icon library.
• Allow clients to omit unsupported icons while retaining labels, descriptions, and selected-state indicators.
• Preserve backward compatibility when metadata is absent or unrecognized.
• Remain presentation-only: an icon must not grant permissions, bypass policy, or be treated as evidence that an operation is safe.

Design questions

• Should this reuse the existing Icon representation, introduce a small vocabulary of semantic hints that clients map to native icons, or support both?
• How should optional per-option metadata align with static enum values and dynamic completion items?
• If resource-backed icons are used, how should the existing trust, SVG-handling, theme, and size guidance apply to configuration pickers?

Expected outcome

Document the chosen representation, fallback behavior, and accessibility expectations, with schema examples/tests for both static and dynamic options. Labels must remain sufficient to understand and operate a picker without icons.

This is a protocol presentation enhancement, not a request to standardize provider-specific permission models or introduce client-side permission adapters.

References

• Configuration and Icon schemas
• Dynamic configuration option schema
• Client-side motivation: microsoft/vscode#335599