feat: v0.3.2 — delete_project tool

Closes the project lifecycle (create → start/stop/redeploy → delete).
The tool calls SYNO.Docker.Project/delete with the UUID JSON-encoded
as the `id` parameter (per DSM convention) and removes only the
Container Manager registration — the project folder and compose
file remain on the NAS. This mirrors DSM's own "Delete project"
behaviour, not a bug; the success message states the folder was
preserved so the user is not surprised.

Safety:
- Project-name validation runs before any I/O.
- A `_find_project` pre-flight returns "not found" with a clear
  message rather than letting DSM reject an unknown UUID.
- No automatic stop. If the project is RUNNING and DSM rejects
  the delete, the response tells the user to `stop_project` first
  rather than silently halting containers under the guise of a
  "delete" call.
- Requires confirmed=True; preview shows name, UUID, status, full
  path, and share path so the user can verify before deleting.

Tests cover preview-only, not-found, invalid-name, happy path
(verifies the UUID is JSON-encoded in the delete call), and the
running-project rejection path that surfaces the stop_project hint.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

CLAUDE.md

@@ -33,11 +33,11 @@ Only a second consecutive failure is treated as a real auth problem.
 
 ---
 
-## Implemented tools (24)
+## Implemented tools (25)
 
 | Category  | Tools |
 |---|---|
-| Projects  | `list_projects`, `get_project_status`, `start_project`, `stop_project`, `redeploy_project`, `create_project` |
+| Projects  | `list_projects`, `get_project_status`, `start_project`, `stop_project`, `redeploy_project`, `create_project`, `delete_project` |
 | Containers | `list_containers`, `get_container_status`, `get_container_logs`, `exec_in_container`, `container_stats`, `delete_container` |
 | Compose   | `read_compose`, `update_compose`, `update_image_tag`, `update_env_var` |
 | Images    | `check_image_updates`, `list_images`, `delete_image` |
@@ -69,9 +69,9 @@ Only a second consecutive failure is treated as a real auth problem.
 ## Implementation rules
 
 - Confirmation required before destructive operations: `stop_project`,
-  `redeploy_project`, `create_project`, `exec_in_container`,
-  `update_image_tag`, `update_env_var`, `update_compose`,
-  `delete_container`
+  `redeploy_project`, `create_project`, `delete_project`,
+  `exec_in_container`, `update_image_tag`, `update_env_var`,
+  `update_compose`, `delete_container`
 - After compose changes: suggest `redeploy_project`
 - DSM errors → human-readable message, no stack traces
 - No secrets in stderr output