GitLab MCP: workItem query fails, workItems works

**Observed behavior**

When querying a GitLab work item via `gitlab_execute_custom_query`, my first attempt used the field `workItem` on `Project`, which failed with:

```
GraphQL error: Field 'workItem' doesn't exist on type 'Project' (Did you mean `workItems`?)
```

Retrying with `workItems(iid: "...")` on `Project` succeeded and returned the expected work item.

**Why this is worth improving**

The GitLab GraphQL schema evidently drifted (either `workItem` was removed/renamed, or it never existed on `Project` and only `workItems` did). The agent-side pattern is:

1. First call fails with a schema error.
2. Agent reads the "Did you mean" hint from the error and adjusts.
3. Second call succeeds.

This works, but it wastes a round-trip on every session that touches work items, and it depends on the agent noticing the hint. A more robust experience would be one of:

- Auto-retry once when the error message contains a `Did you mean` suggestion, substituting the suggested field.
- A schema-aware helper (e.g., `gitlab_get_type_fields` results cached and surfaced in the tool description) so the agent picks the right field on the first try.
- Update any built-in guidance/examples in the GitLab MCP tools to reference `workItems(iid: ...) { nodes { ... } }` as the canonical way to fetch a single work item by IID on a Project.

**Impact**: minor per-call latency + agent context spent on the schema hint. Not blocking, but repeatable across sessions.

---

### Metadata

| Field | Value |
|-------|-------|
| CLI Version | 0.8.10 |
| Platform | darwin |
| Architecture | arm64 |
| OS Release | 25.5.0 |
| Category | improvement |
| Working Directory | feature-1173-parallel-ci-databases |
| Session ID | ses_0c9a0177effeYuBnIpoLd52aQ1 |