intake triage status update 404s on self-hosted instance: SDK calls .../intake-issues/{id}/status but server only accepts PATCH .../intake-issues/{id}/

Environment

• plane-mcp-server 0.2.9 (also present on main/0.3.x and plane-sdk up to 0.2.24)
• Self-hosted Plane instance (PLANE_BASE_URL = https://job.gurupembelajar.com, behind Caddy+uvicorn), workspace slug gpi-it, API key auth

Symptom

plane_update_intake_work_item (tool update_intake_work_item) returns HTTP 404: Not Found: Page not found for every status change (e.g. accepting an intake item with status: 1).

The MCP tool routes status updates through client.intake.update_status() which PATCHes:
GET/PATCH /api/v1/workspaces/{ws}/projects/{proj}/intake-issues/{work_item_id}/status → 404

Root cause (verified)

On this Plane instance the triage write endpoint does not exist. Verified with plain curl:

$ curl -X PATCH https://host/api/v1/workspaces/{ws}/projects/{proj}/intake-issues/{wid}/status/ -d '{"status":1}' -H 'x-api-key: ...'
{"error": "Page not found."}  # 404

$ curl -X PATCH https://host/api/v1/workspaces/{ws}/projects/{proj}/intake-issues/{wid}/ -d '{"status":1}' -H 'x-api-key: ...'
# 200 — triage status accepted

So the per-resource /status suffix added for intake triage (PR #127 area) only exists on Plane Cloud / newer self-hosted API surfaces. On this instance the plain PATCH .../intake-issues/{id}/ update route (SDK intake.update(), same body) performs the same triage change and returns 200.

Note the SDK base path is /workspaces/ and the server 301-redirects to a trailing-slash URL, which requests follows — so redirects are not the issue; the /status suffix itself 404s.

Suggested fix

Make update_status fall back to (or prefer) the plain PATCH .../intake-issues/{id}/ route for triage fields — UpdateIntakeWorkItem carries status/duplicate/snooze in its body anyway, so the dedicated /status route looks redundant on servers that expose it. Alternatively document that update_intake_work_item requires a Plane API version with the /status route.

Workaround today: call the base update endpoint directly (same request body), which works on both.

Start at the MCP tool update_intake_work_item and the client.intake.update_status() entry point, then compare it with intake.update(). Reproduce the 404 on the /status route and the successful response from the base intake-issues/{id}/ route. Done means status updates work against the reported self-hosted API while preserving the existing request body and behavior on supported servers.