DevOps Center tools query the unnamespaced data model only, failing on Managed Package orgs

### Summary

Six of the GA `devops` toolset tools query the **unnamespaced** DevOps Center data model (`WorkItem`, `DevopsProject`) with no Managed Package fallback. On an org running the DevOps Center **managed package** (namespace `sf_devops__`), these tools fail immediately with `sObject type 'WorkItem' is not supported`.

This looks unintended for two reasons:

1. The README points Managed Package users at these tools — it links to [Merge Conflict Resolution with DevOps Center MCP Tools **(Managed Package)**](https://help.salesforce.com/s/articleView?id=platform.devops_center_mcp_intro.htm&type=5).
2. The package **already has** the detection helper and uses it correctly in two tools. `shared/orgType.ts` exports `isManagedPackageDevopsOrg()`, and `sfDevopsDetectConflict.ts` / `sfDevopsResolveConflict.ts` branch on it to pick `fetchWorkItemByNameMP()` vs `fetchWorkItemByName()`. The other tools never call it.

The parallel MP implementations exist in the repo (`getWorkItemsMP.ts`, `getPipelineMP.ts`, `getPipelineStagesMP.ts`) and are covered by tests (`test/getWorkItemsMP.test.ts`) — they're simply not wired into most tool entry points.

### Steps To Reproduce

1. Authenticate against a production org with the DevOps Center managed package installed (namespace `sf_devops__`), with work items and an active pipeline.
2. Configure the server scoped to the devops toolset:
```json
{
"mcpServers": {
"salesforce-dx": {
"command": "npx",
"args": [
"-y", "@salesforce/mcp@latest",
"--orgs", "myOrgAlias",
"--tools", "list_devops_center_projects,promote_devops_center_work_item"
]
}
}
}
```
3. Invoke `list_devops_center_projects` with that org's alias.
4. Invoke `promote_devops_center_work_item` with a valid work item name (e.g. `WI-96271`).

### Expected result

Both tools operate against the managed package objects (`sf_devops__Project__c`, `sf_devops__Work_Item__c`, …), as `detect_devops_center_merge_conflict` already does on the same org.

### Actual result

`list_devops_center_projects`:
```
Error fetching projects:
SELECT Id, Name, Description FROM DevopsProject
^
ERROR at Row:1:Column:35
sObject type 'DevopsProject' is not supported.
```

`promote_devops_center_work_item`:
```
Error fetching work items:
FROM WorkItem
^
ERROR at Row:16:Column:18
sObject type 'WorkItem' is not supported.
```

The managed package objects are present and queryable on the same org with the same authenticated user:
```
$ sf data query --query "SELECT Id FROM sf_devops__Work_Item__c LIMIT 5" --target-org myOrgAlias
Total number of records retrieved: 5.
```

### Additional information

**Root cause.** The failing queries are unnamespaced and unconditional:

- `sfDevopsListProjects.ts` → `exec()` inlines `SELECT Id, Name, Description FROM DevopsProject` (also duplicated in `getProjects.ts::fetchProjects`).
- `sfDevopsPromoteWorkItem.ts` → `exec()` calls `fetchWorkItemsByNames()` from `getWorkItems.ts`, which queries `FROM WorkItem`.

Neither calls `isManagedPackageDevopsOrg()`. For contrast, `sfDevopsDetectConflict.ts` does exactly the right thing:

```ts
const isMP = await isManagedPackageDevopsOrg(connection);
if (isMP) {
// Some orgs expose MP objects but store active DevOps Center data in standard WorkItem.
// Prefer standard WorkItem when present; keep MP as fallback.
const mpWorkItem = await fetchWorkItemByNameMP(connection, effectiveWorkItemName);
...
} else {
workItem = await fetchWorkItemByName(connection, effectiveWorkItemName);
}
```

**Affected tools** (audit of `packages/mcp-provider-devops/src/tools/`, `main`):

| Tool | Queries unnamespaced | Has managed package branch | Works on managed package org |
|---|---|---|---|
| `list_devops_center_projects` | yes | no | ❌ |
| `list_devops_center_work_items` | yes | no | ❌ |
| `promote_devops_center_work_item` | yes | no | ❌ |
| `checkout_devops_center_work_item` | yes | no | ❌ |
| `commit_devops_center_work_item` | yes | no | ❌ |
| `create_devops_center_pull_request` | yes | no | ❌ |
| `detect_devops_center_merge_conflict` | yes | **yes** | ✅ |
| `resolve_devops_center_merge_conflict` | yes | **yes** | ✅ |

Start with shared/orgType.ts and the existing branches in sfDevopsDetectConflict.ts and sfDevopsResolveConflict.ts, then inspect the six affected tools and their helpers: sfDevopsListProjects.ts, getProjects.ts, sfDevopsPromoteWorkItem.ts, getWorkItems.ts, and the checkout, commit, and pull-request entry points. Compare their standard queries with getWorkItemsMP.ts, getPipelineMP.ts, and getPipelineStagesMP.ts, then run test/getWorkItemsMP.test.ts. Done means all affected tools handle managed-package objects without breaking standard-org behavior.

Written by the indexing model from the issue text.