refactor: Align vocabulary — component → program / deployment

Canonical terms (see docs/registry.md glossary):
- program: any catalog entry (tool/daemon/frontend) — the software
- service / job: how a program is deployed (systemd .service / .timer)
- deployment: umbrella for the unified service+job+program view

Changes:
- core: ServiceSpec/JobSpec component: → program: (component accepted as
  back-compat validation_alias); DeployedComponent → Deployment.
- api: ComponentSummary/Detail → DeploymentSummary/Detail; GET /components
  → /deployments; GatewayRoute.component → program; GatewayInfo
  .component_count → deployment_count; ServiceActionResponse/action keys
  component → program.
- app: matching type renames, /components → /deployments hook, route
  /component/:name → /deployment/:name, GatewayRoute.program.
- docs: component-registry.md → registry.md (+ canonical glossary);
  CLAUDE.md endpoint list refreshed (drop removed /tools, add typed
  program/service/job + config routes).

Tests: core 92, cli 24, api 52 green; app build clean; ruff clean.

docs/stacks/python-cli.md

@@ -4,7 +4,7 @@
 > A stack is a template + conventions, not a runtime requirement. `castle create
 > --stack python-cli` scaffolds from it and seeds the program's default dev-verb
 > commands. An existing CLI adopted with `castle add` doesn't need this stack — it
-> declares its own `commands:`. See @docs/component-registry.md for `commands:`,
+> declares its own `commands:`. See @docs/registry.md for `commands:`,
 > `stack:` (optional), and `repo:`.
 
 How to build CLI tools following Unix philosophy.
@@ -344,4 +344,4 @@ programs:
 Tools live in the `programs:` section. If a tool also runs on a schedule,
 add a separate entry in the `jobs:` section referencing the component.
 
-See @docs/component-registry.md for the full registry reference.
+See @docs/registry.md for the full registry reference.