`loadLayeredEnv` refused `DEEPSEEK_BASE_URL` and
`DEEPSEEK_SEARCH_BASE_URL` from every discovered `.env`, including the
user's own `$DSH_HOME/.env`, so a machine-level endpoint written there
made both the CLI and Desktop fail at startup.
The refusal exists for the invoking directory's file: it arrives with a
clone, and a repository must not choose where requests carrying the
user's DeepSeek credential go. The home file is the user's own, and the
profile patches in the same directory can already set these endpoints as
plugin `baseURL` fields, so refusing it there protected nothing.
`HOME_LAYER_PROXY_NAMES` becomes `HOME_LAYER_ROUTE_NAMES` and adds the
two endpoint names; a project `.env` that sets either still fails the
launch, and its message now names the home file as the second way out.
`DSH_HOME` stays bootstrap-only, and the CA and TLS names stay refused
everywhere.
Tests cover the project layer refusing both names, the home layer
accepting both below an exported value, and the project-layer message.
The app-boot, launch-environment, llm-deepseek, and web-search-deepseek
READMEs, the development guide, and the two Agent Notes that stated the
old rule now state this one.
Refs #8138
Yichen Jiang
2284e3e714