Update schemas.ts

[Explorer1092]

Fix GitLabIssueSchema so it accepts the string-array labels returned by GitLab’s Issues API, eliminating the “Expected object, received string” Zod error.

Description

GitLab’s POST /projects/:id/issues endpoint returns labels as a simple string array unless include_labels_details=true is passed.
GitLabIssueSchema currently expects an array of objects, causing Zod to throw:

labels.0: Expected object, received string

This PR updates the schema to accept either a string or a full GitLabLabelSchema object:

labels: z.array(
  z.union([z.string(), GitLabLabelSchema])
)

No runtime logic changes are required—the fix is limited to the schema definition.

Server Details

• Server: gitlab
• Changes to: src/gitlab/index.ts (schema definition only)

Motivation and Context

The mismatch between GitLab’s default response and our Zod schema breaks create_issue, surfacing as an MCP -32603 error for any client supplying labels.
Aligning the schema with the real API removes this blocker for downstream tooling (e.g., AI agents that open issues with labels).

How Has This Been Tested?

• LLM client scenario: Re-ran the failing create_issue call with:

  "labels": ["server-side", "feature-request", "P2"]

  ✅ No error thrown; issue created with correct labels.
• Edge case: Verified again with include_labels_details=true; full-object labels still parse successfully.

Breaking Changes

None. The change is backward-compatible; it only relaxes validation.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature
• Breaking change
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follow MCP security best practices
• I have updated the server's README accordingly (added note about label schema)
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling (schema validation only)
• I have documented all environment variables and configuration options (n/a)

Additional context

• Alternative fix considered: converting string labels to objects post-fetch; rejected because loosens type guarantees downstream.
• This change unblocks any MCP-compatible tooling that relies on GitLab issue creation with labels out-of-the-box.