feat: expose bash risk gate as configurable /settings toggle (persisted in config.toml)

Problem

The destructive-command risk gate in bash_destructive_gate.rs is hardcoded. There is no way for users to disable it when it over-fires on safe commands, or re-enable it after disabling. This is the user-facing counterpart to #751 (which fixes the classifier itself).

Proposed Solution

Expose the risk gate as a configurable, persisted setting:

• Add risk_gate_enabled field to ProviderConfig in jcode-config-types (defaults to true)
• Persist to config.toml so it survives new sessions
• Add /settings TUI command: /settings (show), /settings risk-gate on, /settings risk-gate off
• Support env override JCODE_RISK_GATE_ENABLED=false for per-launch control
• Show status in /config output as Risk gate: enabled/disabled
• When disabled, bash_destructive_gate.rs skips the gate entirely (returns None)

Implementation

Working implementation on my fork (single commit, compiles, 7 tests pass):

https://github.com/alecuba16/jcode/tree/feature/risk-gate-toggle

The gate is enabled by default so existing behavior does not change. Users who hit false positives (like #751) can temporarily disable it with /settings risk-gate off or JCODE_RISK_GATE_ENABLED=false until the classifier itself is fixed.

Tests

7 behavioral tests covering: show status, toggle on/off with persistence verification, invalid value handling, bare subcommand usage, unknown subcommand, and non-matching command rejection. All pass.

Start with bash_destructive_gate.rs and ProviderConfig in jcode-config-types, then trace the existing /settings and /config TUI command paths and config.toml persistence. Check the fork's seven behavioral tests for the intended cases. Done means the setting defaults enabled, persists across sessions, supports the stated command and environment controls, and updates the displayed status.