Editing a service's routing (port, path_prefix, host) and then hitting
"apply" or "gateway reload" — rather than a full deploy — left the running
Caddyfile reflecting the old routing. The Caddyfile was generated from the
derived registry.yaml snapshot, which only `deploy()` rebuilds from
castle.yaml; apply/reload regenerated from that stale snapshot.
Make castle.yaml the single source of truth for local routes:
- caddyfile.py: new shared `service_proxy_targets()` derives a service's
(proxy_path, proxy_host, port, base_url) from its spec. `compute_routes`
now builds local routes from `config.services` when castle.yaml is
loadable, falling back to `registry.deployed` only when it isn't. Since
deploy/apply/reload all funnel through `compute_routes`, every regeneration
path now tracks the spec. Mesh/remote and static-frontend routes unchanged.
- deploy.py: `_build_deployed_service` uses the same shared deriver, so the
written registry and the computed routes can't diverge.
- config_editor.py: `/config/apply` now runs a full `deploy()` (rebuilding
units + Caddyfile and reloading the gateway) before restarting services, so
changed unit ExecStarts actually take effect. Scheduled jobs are no longer
restarted on apply. Drops the now-unused direct caddy-reload path.
- Regression tests: a stale registry's old port/path loses to castle.yaml;
registry fallback still works when config is unavailable.
Paul Payne
b105487790