[FEATURE] Declarative plugin config: non-interactive install --config + plugin config get/set (config-as-code)

Problem

Plugin user configuration (pluginConfigs.<plugin>.options in ~/.claude/settings.json) has no supported non-interactive path. For anyone managing Claude Code as code — fleets of unattended agent users, dotfile/Ansible-provisioned machines, CI — this makes plugins that need config effectively unmanageable:

• claude plugin install collects userConfig interactively (and on some paths fails when it cannot prompt).
• There is no claude plugin config get/set (or install --config key=value) to write options scriptably.
• The pluginConfigs schema is undocumented (related: #76568), so converging it means reverse-engineering settings.json and editing it directly — fragile against every release, and racy against concurrent writers of settings.json.
• Scope semantics are shaky when written out-of-band (related: #77739).

Concrete case

We provision multiple OS users per host, each running the same plugin that needs 4 config values (mode, two service URLs, a namespace). Rebuild-safety requires those values to converge from config management. Today we do a compare-before-write JSON merge into each user's settings.json — undocumented schema, no stability contract.

Feature request

1. claude plugin install <plugin> --config key=value … (non-interactive; fail loud on missing required keys).
2. claude plugin config set <plugin> key=value … / claude plugin config get <plugin> [--json] for already-installed plugins — idempotent, safe against concurrent settings writes.
3. Document the pluginConfigs schema and its scope rules as a stable surface.

That turns plugin config into cattle like everything else in settings.json manageable today (permissions, model, hooks).