feat(grok): manage Grok plugins through grok plugin

[Tryanks]

Summary

Grok plugin management behind the provider-native plugin contract, through grok plugin only.

 crates/agent/src/
 ├── grok.rs
+│   └── grok/plugins.rs            # list / install / uninstall / update / marketplaces via `grok plugin`
 ├── lib.rs
+│   Caps[Grok].plugin_management   # Install, Uninstall, Update; marketplaces; ReloadOrNextSession
+│   ApplyNote::ReloadOrNextSession # skills/commands/hooks/MCP apply after /reload-plugins or next session
 └── tests/fixtures/plugins/
+    └── grok/                      # recorded grok 1.0.46 output, COMMANDS.md, `* -text`

Install consent follows the Claude path's rule: --trust is passed only after the user accepted the challenge whose sha256 is the SHA-256 of Grok's own refusal text.

install alpha@mkt
  grok plugin install alpha@mkt            → exit 1, refusal text
  AcceptCommand { command, sha256(text) }
  on accept(sha256)
    if sha256 != sha256(fresh refusal)     → challenge again, nothing installed
    grok plugin install alpha@mkt --trust  → Done

Deliberately not offered, because the CLI cannot report or scope them honestly: enable/disable (no grok plugin read reports enablement; grok inspect reports a disabled plugin as enabled), uninstall of one plugin from a multi-plugin repository (Grok removes the whole repository), update of path installs. A direct install's source kind comes from grok plugin details (kind: local: / kind: git:), never from host path syntax.

Evidence

Every operation through the production path (examples/probe plugins grok) against the real grok 1.0.46 in a throwaway GROK_HOME, each followed by a native read:

• add marketplace (path and file://) → grok plugin marketplace list --json shows local / git
• install: first run → AcceptCommand{sha256: 73bbb8b2…}, native list []; stale hash → challenge again, native list []; correct hash → Installed 1 plugin(s) from mkt: alpha, native list shows alpha 1.0.0
• update after a version bump → updated 1.0.0 → 1.1.0 (local) and 1.0.0 → 1.2.0 (git); native list agrees
• uninstall → native details zeta → Plugin "zeta" not found
• remove marketplace with installed plugins → listing's confirm set ["alpha@mkt"] matches Grok's uninstalled 1 plugin(s): alpha-…

Settings → Plugins, Grok section (light, default width): entries with their kind badge (Git / local path), user scope, install path, "enable state unknown", and the apply note. Not looked at: dark theme, narrow width.

Tests replay recorded CLI output (provenance in COMMANDS.md): listing ids/actions/confirm sets, direct-install kind from details, --trust only for an accepted current hash, argv never consents and applies GROK_HOME, update outcome as Grok prints it.

Checks (macOS): cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings, cargo nextest run --workspace --locked (936 passed, 11 skipped), cargo machete, wasm / iOS-sim / Android checks with -D warnings, and Windows cross-compile Clippy for agent, services and runtime. Each commit builds and passes Clippy.

Two tests failed on Windows in an earlier run of this code and were settled per CONTRIBUTING: source-kind classification was a product defect (host path syntax) → now read from details; the sha256 mismatch was the checkout converting the hashed fixture to CRLF → .gitattributes pins those fixtures. This PR's CI is their first Windows run since.

Merge Danger

Door: two-way — revert restores PluginManagement::NONE for Grok; no persisted state is written by Tcode (Grok's own files stay the truth).

Blast Radius: Grok-only

Off by default: per-provider plugin management defaults to off except Codex, so nothing runs until the user enables Grok in Settings → Plugins. Not verified: Windows execution of the plugin tests (CI), a real xAI login, and whether a running session picks up changes without /reload-plugins (the apply note says reload or next session, as observed).