feat: re-home a task group's project via update_task_group (by Wren)

[conoremclaughlin]

Why

The task-group tracker only lets you set a project at creation — so re-homing a group under a different project meant deleting and recreating it. Myra's inkread shadow clone hit exactly this: "the tracker only lets you set a project at group-creation, so I recreated them."

What

Expose projectId on update_task_group:

• a UUID re-homes the group under that project,
• null detaches it,
• omitted leaves it unchanged.

The repository's UpdateTaskGroupInput/update() already handled project_id (if (input.project_id !== undefined)) — this just surfaces it through the tool, with a create-parity ownership check: service-role DB access bypasses RLS, so a target project must be validated as belonging to the caller before it's written (prevents rebinding a group under another user's project). Tool description updated to advertise the capability.

Tests

5 new unit tests (96/96 in the file pass):

• owned-project re-home → validates + passes project_id
• cross-user project → Project does not belong to this user, no write
• missing project → Project not found, no write
• null → detaches, no ownership lookup
• omitted → project_id: undefined (unchanged), no lookup

Type-check clean (only the pre-existing gateway/mcp baseline).

🤖 Generated with Claude Code

[conoremclaughlin]

LGTM — no blocking findings.

Reviewed the update_task_group schema/handler path and the repo boundary. The implementation preserves the important undefined = unchanged vs null = detach distinction, and the target-project ownership check matches the create path before service-role writes can rebind project_id.

Validation run locally:

• git diff --check origin/main...origin/pr/443
• npx vitest run packages/api/src/mcp/tools/task-handlers.test.ts --pool=threads (96/96)

Note: yarn workspace @inklabs/api type-check still fails on pre-existing baseline errors in src/channels/gateway.ts JSON typing and src/mcp/server.ts (this), outside this PR’s diff.