refactor(cli): resource-first command surface

Names collide across resource types (a program and a service can share a name),
so the CLI no longer resolves bare names. Operations live under the resource
they act on; platform lifecycle and the cross-resource overview stay top-level.

  castle program  list|info|create|add|clone|delete|run|install|uninstall|
                  build|test|lint|format|type-check|check
  castle service  list|info|create|delete|deploy|enable|disable|start|stop|restart|logs
  castle job      <same verbs>   (create takes --schedule)
  castle gateway  start|stop|reload|status
  castle list | status | deploy [name]        # cross-cutting
  castle start | stop | restart               # whole platform (systemd verbs)

Key changes:
- info/delete/list/run are resource-scoped (no more cross-section name match).
- delete only removes the named resource's entry; program delete still blocks
  when a deployment references it.
- per-resource start/stop/restart (systemctl on the unit/timer); top-level
  start/stop/restart act on the whole platform.
- expose → 'service create' (more general: --program ref, --runner); gained
  'job create' (the CLI never had one).
- dropped up/down — bringing things online is the honest 'deploy && start'.

Docs (CLAUDE.md, registry.md, stack guides) and user-facing messages updated.
core 94 / cli 24 / api 52 green; ruff clean. Verified live: program/service/job
list+info scope correctly, service create+scoped-delete round-trips.

docs/stacks/python-cli.md

@@ -1,9 +1,9 @@
 # Python Tools in Castle
 
 > **This is a stack — creation-time guidance for writing _new_ CLI tools.**
-> A stack is a template + conventions, not a runtime requirement. `castle create
+> A stack is a template + conventions, not a runtime requirement. `castle program 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
+> commands. An existing CLI adopted with `castle program add` doesn't need this stack — it
 > declares its own `commands:`. See @docs/registry.md for `commands:`,
 > `stack:` (optional), and `repo:`.
 
@@ -49,7 +49,7 @@ Examples: `code/pdf2md/`, `code/gpt/`, `code/protonmail/`
 ## Creating a new tool
 
 ```bash
-castle create my-tool --stack python-cli --description "Does something"
+castle program create my-tool --stack python-cli --description "Does something"
 cd ~/.castle/code/my-tool && uv sync
 ```
 

docs/stacks/python-fastapi.md

@@ -1,9 +1,9 @@
 # Web APIs in Castle
 
 > **This is a stack — creation-time guidance for writing _new_ FastAPI services.**
-> A stack is a template + conventions, not a runtime requirement. `castle create
+> A stack is a template + conventions, not a runtime requirement. `castle program create
 > --stack python-fastapi` scaffolds from it and seeds the program's default
-> dev-verb commands. An existing service adopted with `castle add` doesn't need
+> dev-verb commands. An existing service adopted with `castle program add` doesn't need
 > this stack — it declares its own `commands:`. See @docs/registry.md
 > for `commands:`, `stack:` (optional), and `repo:`.
 
@@ -442,10 +442,10 @@ uv run ruff format .        # Format
 
 ## Scaffolding
 
-`castle create` generates all of this automatically:
+`castle program create` generates all of this automatically:
 
 ```bash
-castle create my-service --stack python-fastapi --description "Does something useful"
+castle program create my-service --stack python-fastapi --description "Does something useful"
 ```
 
 See @docs/registry.md for manifest fields, castle.yaml structure,

docs/stacks/react-vite.md

@@ -1,9 +1,9 @@
 # Web Frontends in Castle
 
 > **This is a stack — creation-time guidance for writing _new_ frontends.**
-> A stack is a template + conventions, not a runtime requirement. `castle create
+> A stack is a template + conventions, not a runtime requirement. `castle program create
 > --stack react-vite` scaffolds from it and seeds the program's default dev-verb
-> commands. An existing frontend adopted with `castle add` doesn't need this
+> commands. An existing frontend adopted with `castle program add` doesn't need this
 > stack — it declares its own `commands:`. See @docs/registry.md for
 > `commands:`, `stack:` (optional), and `repo:`.