[feature]: Support reordering modules via API and MCP

Summary

Plane modules expose a sort_order field and the web app can reorder modules manually, but the public API and the official MCP server do not provide a supported way to update module order.

This makes it impossible for integrations or AI agents to persist a manual module order without using browser automation or destructive workarounds.

Current behavior

• GET /api/v1/workspaces/{workspace_slug}/projects/{project_id}/modules/ returns modules with sort_order.
• PATCH /api/v1/workspaces/{workspace_slug}/projects/{project_id}/modules/{module_id}/ accepts documented module fields such as name, description, start_date, target_date, status, lead, members, external_source, and external_id.
• Sending sort_order to the public module PATCH endpoint returns a successful response but does not update the module order.
• The official Plane MCP server exposes list_modules and update_module, but update_module does not accept sort_order or provide a reorder-specific tool.

Expected behavior

Please support reordering modules through the public API and MCP, either by:

1. allowing sort_order in the public module update endpoint, or
2. adding a dedicated module reorder endpoint, for example:

PATCH /api/v1/workspaces/{workspace_slug}/projects/{project_id}/modules/{module_id}/reorder/

with a payload such as:

{
  "sort_order": 15535.0
}

The official MCP server could then expose this as either:

update_module(..., sort_order=...)

or a dedicated tool:

reorder_module(project_id, module_id, sort_order)

Why this should be worked on

Plane already treats module order as a first-class value in reads and in the web UI. Exposing the same capability through the public API would make module ordering automation possible for migrations, sync tools, scripts, and MCP-based agents.

Without this, integrations can list modules in manual order but cannot persist a new manual order safely. The only alternatives are browser automation or destructive workarounds such as recreating modules, which changes module IDs and risks data loss.

Example use case

An automation agent reads a project's modules and wants to arrange them in a meaningful manual order, for example:

1. Health
2. Finances
3. Career
4. Personal development
5. Family and friends
6. Romantic relationships
7. Fun and recreation
8. Physical environment

The agent can compute the intended order but cannot persist it via API/MCP today.

Start by tracing the public module PATCH endpoint and the official MCP tools named in the issue: list_modules and update_module. Decide how reordering should be exposed, then verify that a module's sort_order can be changed through the API and persisted through the MCP interface.