feat: v0.6.0 — read build_stream log instead of dropping it (#2)

DSM emits a readable plaintext build log over the build_stream HTTP
body (one short status line per step) and closes the connection when
the build is done. The 0.2.5 implementation sent the request and
dropped the body unread, leaving users with nothing more than a
BUILD_FAILED polling status and no actionable diagnostic.

DsmClient.trigger_build_stream now consumes the body line-by-line and
returns the collected log as a string. Wall-clock budget of 210 s
(under the Claude Desktop ~4 min ceiling); on timeout the partial log
is returned with a "[build_stream: timeout — stream still open
server-side]" marker so callers know the build continues server-side.
Per-chunk ReadTimeout is treated the same way. JSON error envelope,
transport-error mapping (M-4), and SID-scrubbed HTTP-error formatting
are unchanged.

redeploy_project and create_project now parse the returned log via
_parse_build_stream_log (any line containing "Error response from
daemon:" or ending in " Error" counts as a failure). On a failed log
the tools abort immediately, surface the daemon line(s) in the result
(e.g. "Error response from daemon: manifest for nginx:9.9.9 not
found: manifest unknown"), and skip the polling step. The BUILD_FAILED
polling guard (M-5) stays as a second safety net for late failures
where the stream was clean but the container exited after start.

No new MCP tool: the build log is a live stream and cannot be
re-fetched after the build ends, so it is surfaced during
redeploy_project / create_project rather than exposed as a standalone
get_project_build_log call.

Minor version bump because redeploy_project and create_project return
materially different strings on a failed build and exit earlier in
the failure path. Signatures unchanged.

Tests: streamed-log collection, daemon-error log, header ReadTimeout
marker, per-chunk ReadTimeout partial log, wall-clock budget
truncation, _parse_build_stream_log unit tests, redeploy/create end-
to-end behavior with a failing log.

Closes #2

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

CLAUDE.md

@@ -56,6 +56,20 @@ Only a second consecutive failure is treated as a real auth problem.
 - **Async project start** — `SYNO.Docker.Project/start` returns immediately
   while containers are still initialising.  `redeploy_project` polls
   `SYNO.Docker.Project/list` every 2 s for up to 30 s after issuing start.
+- **`SYNO.Docker.Project/build_stream`** — returns a streamed plaintext
+  build log (content-type `text/html`), one short line per step:
+  `Container <name> Running` on success, `<svc> Error` followed by
+  `Error response from daemon: <cause>` on failure. The stream closes
+  when the build is done. `DsmClient.trigger_build_stream` consumes the
+  body line-by-line with a 210 s wall-clock budget (under the Claude
+  Desktop ~4 min ceiling) and returns the log as a string; on timeout
+  the partial log is returned with a marker appended so callers know
+  the build is still running server-side. `redeploy_project` and
+  `create_project` grep the returned log for daemon errors and abort
+  early — these errors are much more actionable than the eventual
+  `BUILD_FAILED` polling status. The log is **live-only**: it cannot
+  be re-fetched after the build ends, which is why no standalone
+  `get_project_build_log` tool exists.
 - **Image delete** — requires a form-encoded POST with a JSON `images` array
   (confirmed via browser DevTools); uses `DsmClient.post_request()`.
 - **`SYNO.Docker.Image/pull` vs. `pull_start`** — the legacy `pull` method