feat(config): round-trip user-owned extra_request_params through provider edit

[Brian Krabach (bkrabach)]

Summary

Provider modules are adopting an extra_request_params config key -- an owner-beware dict merged verbatim into every API request, for parameters the module itself doesn't wrap. Users maintain this key by hand in settings.yaml.

Problem: every provider config-rewrite path (configure_provider() and its callers in provider_config_utils.py/commands/provider.py) rebuilds a provider's config purely from the module's declared ConfigField schema answers, then assigns the rebuilt dict wholesale over the old one. Any key not declared as a ConfigField -- including extra_request_params -- was silently dropped on reconfigure, defeating the whole point of a hand-maintained passthrough bag.

Fix: a single, narrow helper -- _preserve_reserved_keys(old, new) in amplifier_app_cli/provider_config_utils.py, backed by RESERVED_PROVIDER_CONFIG_KEYS = ("extra_request_params",) -- carries the key forward verbatim from the prior config into the rebuilt one, if present. Applied at every seam in amplifier_app_cli/commands/provider.py that replaces an existing provider instance's config:

• provider_edit() (commands/provider.py:946 pre-patch) -- primary provider edit CLI path
• _manage_edit_provider() (commands/provider.py:1502 pre-patch) -- interactive provider manage edit path
• provider_add() same-module replace-without-id branch -- covers a concurrent-write race that could otherwise drop the key
• _manage_add_provider() same branch, interactive-loop variant

extra_request_params is never a ConfigField: never prompted for, never displayed in the wizard, never validated. A fresh add (no prior config) never invents the key. Any other non-schema key continues to be dropped on edit exactly as before -- the preservation is deliberately narrow (see test (b)).

Tests

New file: tests/test_provider_config_reserved_keys.py

• (a) edit flow preserves extra_request_params verbatim (CLI provider edit + interactive _manage_edit_provider)
• (b) edit flow still drops an unrelated non-schema key (some_stale_key) -- preservation stays narrow
• (c) the wizard never prompts for extra_request_params, even with an empty config_fields schema
• (d) a fresh provider add (no prior config) never invents the key (CLI + interactive)
• (e) direct unit coverage of _preserve_reserved_keys()

Fail-before/pass-after (via git stash): with the implementation (provider_config_utils.py + commands/provider.py changes) stashed, 7 of 11 new tests fail --the seams drop the key and the helper is undefined. Restored, all 11 pass.

Full suite: 1508 passed (1497 baseline + 11 new), 1 skipped, 13 deselected, 1 xfailed -- no regressions.

Docs

Added a short paragraph to README.md (Provider management section) documenting the convention: extra_request_params is user-owned, round-tripped by config tooling, never wizard-prompted, contents are the user's responsibility.

Merge note

This PR is self-authored/merged by the repo maintainer (via automation acting at their direction). It will only be merged with --admin after all required checks are green -- never over a failing check.

🤖 Generated with Amplifier

[Brian Krabach (bkrabach)]

All required checks are green (license/cla + full 9-job pytest/integration matrix — see checks tab). This PR is self-authored and merged via the maintainer admin-merge path, executed by automation acting at the repo maintainer's explicit direction, per the documented process for this class of change. Merging with `--admin` to bypass the required-review gate (no other reviewers available in this workflow) since all status checks passed and no check is being overridden.