fix(acp): forward Pi model selection to the adapter

[fatwang2]

Problem

The Pi (ACP) provider's model selection was display-only. goose read the adapter-advertised model config option to populate the picker, but whatever you selected never reached pi-acp — it kept using the Pi Droid session's default model. The UI (or Buzz's set_model) showed one model while a different one served the session.

Root cause

pi_acp.rs built its AcpProviderConfig with model_config_option_id: None. The generic ACP provider only pushes a model choice to the agent (via session/set_config_option) when that id is Some; with None, apply_model_if_changed short-circuits and sends nothing.

Fix

I verified against the installed adapter (pi-acp) that it advertises the model as a config option with id "model" (MODEL_CONFIG_ID), and its setSessionConfigOption handler applies the value via setSessionModel → proc.setModel(provider, id) (with provider/id parsing for prefixed IDs). So the adapter fully supports model changes over ACP.

Wire the picker's selection through by setting model_config_option_id: Some("model"), mirroring the Copilot provider — the only one that previously wired this up. Also populate session_config_options at session creation when a concrete model is configured, so resumed or switched sessions use the requested model instead of the agent default.

This is the same pattern as #10675 (which fixes the equivalent issue for the Claude Code ACP provider).

Testing

cargo check -p goose-providers passes. The apply_model_if_changed behavior is already covered by generic tests in acp/provider.rs (apply_model_if_changed_sends_set_config_option_on_change, apply_model_if_changed_skips_when_model_unchanged, apply_model_if_changed_noop_without_option_id, apply_model_if_changed_skips_sentinel_model); this is a one-line config change with no new branching to test (Copilot's identical config is likewise untested at the provider level).

Note: cargo check -p goose (full crate) could not be run locally due to a macOS 27 / sqlx_macros proc-macro dylib compatibility issue ("mis-aligned LINKEDIT string pool"), but the goose-providers crate that contains this change compiles cleanly.