revert: restore _poll_task and dir_size/get_md5 to 0.2.2 state

All changes since 0.2.2 to _poll_task, dir_size, and get_md5 (window_timeout,
_poll_oneshot, start_and_poll_immediately) are reverted. The 0.2.2 behaviour
worked reliably for small directories and is the last known-good baseline.

The remaining known limitation (occasional 599 on large directories) is
documented in SPEC.md. Retry the operation as a workaround.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

SPEC.md

@@ -402,3 +402,27 @@ Validate config, resolve credentials, test login, list available FileStation API
 Load config and credentials, create `FileStationClient` (lazy — no immediate connection),
 create and run `FastMCP("mcp-synology-filestation")` over stdio. Uses `anyio.run()` for
 Windows compatibility.
+
+
+---
+
+## Known Limitations
+
+### `dir_size` / `get_md5`: occasional "DSM error code 599" on large directories
+
+DSM's `DirSize` and `MD5` APIs are one-shot: once `finished=true` is returned
+by the status endpoint, the task is removed and all subsequent polls return
+error 599. The MCP server polls immediately after `start` (no initial delay)
+and retries up to 5 consecutive 599 responses before giving up.
+
+For small directories and files the result is reliably read on the first or
+second poll. For large directories (e.g. `/docker`, `/music`) the task takes
+longer; if DSM removes the completed result between two polls the tool returns
+`Error: DSM error code 599`. Retrying the operation usually succeeds.
+
+Root cause is not fully understood. The raw HTTP test script (`test_dirsize_md5.py`)
+reliably catches `finished=true` for the same paths, suggesting the issue is
+related to timing in the MCP stdio event loop.
+
+**Workaround:** retry the `dir_size` call. It succeeds on the second or third attempt
+for most paths.