pi: providers can come from ~/.config/pi/models.d, like settings already do

models.json was a plain symlink to the tracked file, which left a machine whose
models are served from somewhere other than a vendor's own API with nowhere to
say so. pi reads providers from exactly one path -- join(getAgentDir(),
"models.json") -- and a `providers` block in a settings fragment is inert,
because the settings schema has no such key. So on such a machine pi cannot be
used at all, and the endpoint is not something this repo may name.

link/pi.sh now generates models.json the way it already generates settings.json:
the repo's file, then every ~/.config/pi/models.d/*.json. No three-way merge
here -- pi never writes this file, keeping runtime state in the sibling
models-store.json -- so a hand-edit of ~/.pi/agent/models.json no longer
survives a relink. Put it in a fragment.

It reports which provider came from which fragment, added or replaced, so a
local file shadowing a provider the repo ships cannot do it quietly.

Proposed as a change request from the machine that needs it; verified here
against pi 0.84.2 before applying.

1 files changed, 2 insertions, 3 deletions

diff --git a/link.sh b/link.sh
index 53bbf85..4f5bbff 100755
--- a/link.sh
+++ b/link.sh
@@ -36,9 +36,8 @@ link_all "$config_dir/bat" "$xdg_config_dir/bat"
 
 link "$config_dir/aider.conf.yml" "$HOME/.aider.conf.yml"
 link "$config_dir/pi/extensions" "$HOME/.pi/agent/extensions"
-link "$config_dir/pi/models.json" "$HOME/.pi/agent/models.json"
-# settings.json is generated by link/pi.sh; AGENTS.md and mcp.json, if any,
-# come from another layer.
+# settings.json and models.json are both generated by link/pi.sh; AGENTS.md and
+# mcp.json, if any, come from another layer.
 
 # Utils
 bin="$HOME/.bin"