[Feature] getDefinition / long-running operations require hand-rolled polling; no MCP tool polls to completion

@AmosHersch is already working on this.

Since Aug 18, 2026.

**Describe the bug**
This is a feature request. `items/{id}/getDefinition` (and other long-running Fabric operations) return `202 Accepted` with `Location` and `x-ms-operation-id` headers and an empty body. There is no MCP tool that polls this to completion and returns the decoded result -- every caller has to hand-roll the poll loop (`GET /v1/operations/{id}` until status is terminal, then `GET /v1/operations/{id}/result`) themselves in whatever scripting environment they're using.

**Expected behavior**
A tool like `core_get-item-definition(workspace-id, item-id)` that internally polls the LRO to completion and returns the decoded definition parts directly, removing the need for callers to implement their own polling/backoff logic.

**Actual behavior**
Every retrieval of a notebook or pipeline definition required manually:
1. POST to `getDefinition`
2. Check for `202` status + extract `x-ms-operation-id` header
3. Poll `GET /v1/operations/{id}` on an interval until `status` is `Succeeded`/`Failed`
4. GET `/v1/operations/{id}/result` for the actual payload
5. Base64-decode each `definition.parts[].payload`

This boilerplate was repeated many times across a single session building a Fabric Data Pipeline + notebooks.

**Reproduction Steps**
1. Call `items/{itemId}/getDefinition` on any Fabric item
2. Observe a `202` with `Location`/`x-ms-operation-id` headers and no body
3. Note no MCP tool exists to poll this LRO to completion

**Environment**
- Fabric MCP Server / Fabric REST API `v1`
- Windows 11