fix: v0.5.1 — pull_image API (Image/pull_start, not Registry/pull_start)

The 0.5.0 prompt mis-attributed the API: pull_start lives on
SYNO.Docker.Image, not SYNO.Docker.Registry (live DSM capture).
search and tags ARE correctly on Registry; only pull_start belongs
to Image. Registry/pull_start returns "Method does not exist".

Parameters are unchanged (repository + tag both JSON-encoded), and
the Image/list polling for completion detection is untouched.

Tests updated to assert SYNO.Docker.Image/pull_start. CLAUDE.md
DSM-quirks section consolidates the Image vs. Registry split so
this trap is documented for future surface additions. References
#3 (already closed).

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

CLAUDE.md

@@ -58,14 +58,19 @@ Only a second consecutive failure is treated as a real auth problem.
   `SYNO.Docker.Project/list` every 2 s for up to 30 s after issuing start.
 - **Image delete** — requires a form-encoded POST with a JSON `images` array
   (confirmed via browser DevTools); uses `DsmClient.post_request()`.
-- **`SYNO.Docker.Image/pull`** — API method exists but behaviour varies by
-  DSM version; not exposed as a standalone tool. `pull_image` uses
-  `SYNO.Docker.Registry/pull_start` instead (see below).
-- **`SYNO.Docker.Registry/pull_start`** — asynchronous pull entry point;
-  no matching `pull_status` method confirmed. `pull_image` polls
-  `SYNO.Docker.Image/list` until `repository:tag` appears (2–10 s backoff,
-  240 s budget) and returns a "still running" hint on timeout instead of
-  raising — DSM keeps pulling server-side regardless of the HTTP response.
+- **`SYNO.Docker.Image/pull` vs. `pull_start`** — the legacy `pull` method
+  exists but behaviour varies by DSM version; not exposed as a standalone
+  tool. `pull_image` uses `SYNO.Docker.Image/pull_start` (asynchronous
+  pull entry point) with both `repository` and `tag` JSON-encoded. Note
+  that `pull_start` lives on **`SYNO.Docker.Image`**, NOT on
+  `SYNO.Docker.Registry` — the Registry API only exposes the synchronous
+  read-only methods (`search`, `tags`, `get/set/create/delete`, `using`);
+  calling `Registry/pull_start` returns "Method does not exist". No
+  matching `pull_status` method is confirmed on either API, so completion
+  is detected by polling `SYNO.Docker.Image/list` until `repository:tag`
+  appears (2–10 s backoff, 240 s budget). Timeout returns a "still
+  running" hint instead of raising — DSM keeps pulling server-side
+  regardless of the HTTP response.
 - **`SYNO.Docker.Registry/tags`** — uses `repo` (JSON-encoded) as the
   parameter name; the n4s4 reference's `name` does not work on this DSM
   version. Returns the tag list as the envelope's `data` field directly,