Add a persisted opt-in setting for Destructive Command Guard #1057

Parent

Part of #1049. This is the third independently reviewable slice of the Destructive Command Guard work.

Dependency

Depends on the DCG binary service so enabling the setting can verify that DCG is available.

Problem

Users need an explicit, persisted opt-in control for DCG. The setting must complete the full storage-to-webview round trip and must not remain enabled when installation is unavailable.

Scope

• Add destructiveCommandGuardEnabled to shared global settings and extension-host state.
• Return the setting from provider state with consistent default semantics.
• Bind the Auto-Approve control to SettingsView local cached state and include it in the save payload.
• Attempt DCG installation when enabling; on failure, normalize the saved value back to disabled and show a localized error.
• Add localized settings/error strings and focused extension/webview tests.
• Preserve the current allowlist/denylist controls when DCG is disabled and explain the opt-in behavior in settings.

Out of scope

• Changing auto-approval decisions.
• Running DCG before command execution.
• Denied-command chat presentation.

Acceptance criteria

• The setting validates, persists, and round-trips from storage to the webview.
• The settings control reads/writes local cachedState, not live extension state.
• Enabling verifies installation before persistence.
• Failed installation leaves the setting disabled and displays a localized error.
• Disabled/unset behavior preserves the existing command allowlist/denylist UX.
• Focused provider, message-handler, and settings UI tests pass.
• The stacked branch type-checks/builds independently.

Stack

Base: the DCG service PR. The command-policy integration issue will build on this issue.