create_work_item_relation hits /dependencies/ which self-hosted Plane CE doesn't expose — older /relations/ endpoint works

Environment

• plane-mcp-server version: 0.2.10 (installed via uvx, stdio transport)
• Auth: PLANE_API_KEY + PLANE_WORKSPACE_SLUG env vars
• Plane instance: self-hosted Community Edition 1.3.1 (same edition/version as #169 / #170 / #172)

Bug

create_work_item_relation (and list_work_item_relations) call the dependencies API surface, which POSTs/GETs against:

/api/v1/workspaces/{slug}/projects/{project_id}/work-items/{work_item_id}/dependencies/

This endpoint 404s on self-hosted CE 1.3.1:

$ curl -s -w "\nHTTP:%{http_code}\n" -X POST \
  -H "x-api-key: $PLANE_API_KEY" -H "Content-Type: application/json" \
  -d '{"relation_type": "blocking", "work_item_ids": ["<target-uuid>"]}' \
  "https://<self-hosted-host>/api/v1/workspaces/<slug>/projects/<project_id>/work-items/<work_item_id>/dependencies/"

{"error": "Page not found."}
HTTP:404

There is an older endpoint that does exist on this same instance and accomplishes the same thing:

/api/v1/workspaces/{slug}/projects/{project_id}/work-items/{work_item_id}/relations/

with body {"relation_type": "blocking", "issues": ["<target-uuid>", ...]} (note: field is issues, not work_item_ids):

$ curl -s -w "\nHTTP:%{http_code}\n" -X POST \
  -H "x-api-key: $PLANE_API_KEY" -H "Content-Type: application/json" \
  -d '{"relation_type": "blocking", "issues": ["<target-uuid>"]}' \
  "https://<self-hosted-host>/api/v1/workspaces/<slug>/projects/<project_id>/work-items/<work_item_id>/relations/"

[{"id": "<target-uuid>", ..., "relation_type": "blocked_by", ...}]
HTTP:201

A plain GET against the same /relations/ path also works and returns the six-direction grouping (blocking, blocked_by, duplicate, relates_to, start_after, start_before, finish_after, finish_before), so it looks like a full drop-in replacement for the dependencies calls in plane/api/work_items/dependencies.py.

Separately, list_work_item_relation_definitions also 404s on this instance. That tool's own docstring instructs callers to "Always call list_work_item_relation_definitions first" before create_work_item_relation — so on CE, the documented workflow is broken before you even get to the relation-creation call.

Root cause (same shape as #172)

Same underlying issue as the -lite endpoints in #169/#170/#172: the SDK targets newer API routes (/dependencies/) that ship on plane.so cloud but aren't present on self-hosted CE 1.3.1, which only has the older /relations/ route.

Suggested fix

Mirror the fallback approach proposed in #172 for the -lite routes: detect a 404 on /dependencies/ and fall back to the older /relations/ endpoint (translating work_item_ids -> issues in the request body, and the response shape back for callers). Given #171 is asking whether CE is a supported target at all, it might be worth consolidating these into one tracking issue for "SDK routes not present on self-hosted CE 1.3.1."

Repro steps

1. Point plane-mcp-server at a self-hosted Plane CE 1.3.1 instance via PLANE_BASE_URL + PLANE_API_KEY + PLANE_WORKSPACE_SLUG.
2. Create two work items in a project.
3. Call create_work_item_relation with relation_type="blocking" between them.
4. Observe HTTP 404: Not Found: Page not found. even though the API key, workspace, and project are all valid (confirmed via retrieve_project, list_labels, list_states, which all succeed against the same project).

Start in plane/api/work_items/dependencies.py and trace the create and list relation calls, then reproduce the 404 against Plane CE 1.3.1 using the supplied curl shape. Implement the documented fallback to /relations/ with its issues field and verify that relation creation, listing, and the relation-definitions workflow work on CE while preserving the existing dependencies behavior.