/admin/api/system/reload built a bare `Request({})` in order to reach
`app.state.config_mgr`, which raises on the first attribute: the endpoint
answered 500 to every call it ever received and had never reloaded anything.
An operator editing a config file by hand therefore had no way to apply the
edit except restarting the server.

That matters most for a pod pool. A pool reads its ceilings -- max_pods,
gpu_types, the cost caps -- out of models_data on every acquisition, so an
edit the process has not re-read is an edit that does not apply, and the
operator's only lever was a restart that drops whatever is in flight.

The handler now takes the injected Request and falls back to the manager that
set_config_manager installed, because the front proxy and the engine do not
both populate app state. It reloads BOTH files and reports how many model
entries it re-read, so a caller can see that the reload reached models.json
and not only config.json.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM