[Bug]: outputSchema emits boolean subschema `properties.result: true`, rejected by strict MCP clients (21 of 26 tools)

### Description

`tools/list` returns `outputSchema` objects where the `result` property is the
boolean schema `true` rather than a schema object:

```json
{ "type": "object", "properties": { "result": true }, "required": ["result"] }
```

Boolean subschemas are legal JSON Schema (draft-06 and later, where `true` is the
always-valid schema), but they are rejected by MCP clients that validate tool
definitions with zod-shaped validation — the pattern used by the MCP TypeScript
SDK. Because `tools/list` is validated as a whole, one rejected subschema fails
the entire response, so **no tools register at all** and the server is unusable
rather than partially degraded.

This affects **21 of 26 tools**. The 5 unaffected tools declare fully specified
`outputSchema` objects, so the fix is consistent with what the server already
emits elsewhere.

Affected: `cancel_deployment`, `create_budget`, `create_deployment`,
`create_or_update_resource`, `create_or_update_resource_group`, `forecast_costs`,
`get_async_operation_status`, `get_benefit_recommendations`, `get_budget`,
`get_deployment_status`, `get_resource_type_schema`, `get_retail_prices`,
`list_alerts`, `list_benefit_utilization`, `list_budgets`, `list_dimensions`,
`list_reservation_transactions`, `list_resource_types`, `query_aks_costs`,
`query_costs`, `whatif_deployment`

Unaffected: `execute_query`, `generate_query`, `get_pricesheet_status`,
`start_pricesheet_download`, `validate_query`

### Steps to Reproduce

1. Obtain a token for the ARM MCP resource:

```powershell
$t = (Get-AzAccessToken -ResourceUrl 'api://22bfbae3-f4e7-485f-be43-8cee15065084').Token |
ConvertFrom-SecureString -AsPlainText
$h = @{ Authorization = "Bearer $t"; Accept = 'application/json, text/event-stream' }
$u = 'https://mcp.management.azure.com'
```

2. Initialize, then call `tools/list`:

```powershell
$h['x-mcp-toolset'] = 'CostManagement,Pricing' # counts below assume this toolset
Invoke-WebRequest -Uri $u -Method Post -Headers $h -ContentType 'application/json' -Body '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"repro","version":"1"}}}' | Out-Null
$r = Invoke-WebRequest -Uri $u -Method Post -Headers $h -ContentType 'application/json' -Body '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'
([regex]::Matches($r.Content, '"result"\s*:\s*true')).Count
```

3. This prints `21`. Without the `x-mcp-toolset` header the default set is 12
tools of which 9 are affected — the defect is identical, only the counts
differ by toolset.

4. Alternatively, connect any MCP client that validates tool schemas strictly
(e.g. Claude Code) and observe that the tools fetch fails.

### Expected Behavior

tools/list returns outputSchema definitions that all MCP clients can validate.
For an unconstrained property, emit the equivalent empty schema object:

"properties": { "result": {} }

Tools register and become callable.

### Actual Behavior

The client rejects the `tools/list` response and registers zero tools. The server
shows as connected but with no capabilities:

```
Status: connected · tools fetch failed
Auth: authenticated
Capabilities: none
```

with one validation error per affected tool:

```json
{ "code": "custom", "path": ["tools", 1, "outputSchema", "properties", "result"], "message": "Invalid input" }
```

### VSCode Version

N/A — reproduced outside VS Code, with Claude Code v2.1.220 on Windows 11. Also reproducible with a raw HTTP client (see Steps to Reproduce), so the issue is independent of any particular client.

### ARM MCP Server Version

1.265.0.0

### Model Being Used

N/A — the failure occurs during the MCP handshake, before any model interaction. (Environment was Claude Opus via Claude Code.)

### Trace ID

_No response_

### Logs / Screenshots

Full client-side validation failure (Claude Code v2.1.220), one entry per
affected tool — 21 in total:

```json
[
{ "code": "custom", "path": ["tools", 1, "outputSchema", "properties", "result"], "message": "Invalid input" },
{ "code": "custom", "path": ["tools", 3, "outputSchema", "properties", "result"], "message": "Invalid input" },
{ "code": "custom", "path": ["tools", 4, "outputSchema", "properties", "result"], "message": "Invalid input" },
{ "code": "custom", "path": ["tools", 6, "outputSchema", "properties", "result"], "message": "Invalid input" },
{ "code": "custom", "path": ["tools", 7, "outputSchema", "properties", "result"], "message": "Invalid input" }
]
```

…continuing for tool indices 8–18, 20–23 and 25.

The offending payload, verbatim from `tools/list`:

```json
{
"name": "get_async_operation_status",
"outputSchema": { "type": "object", "properties": { "result": true }, "required": ["result"] }
}
```

### Additional Context

**Suggested fix** — emit `{}` instead of `true`. Semantically identical in JSON
Schema, and compatible with strict validators:

```diff
- "properties": { "result": true }
+ "properties": { "result": {} }
```

**Impact** — this blocks every MCP client using the reference TypeScript SDK's
validation. Since the failure is all-or-nothing at `tools/list`, affected clients
get zero tools rather than the 5 valid ones. It may be part of why the preview is
currently limited to GitHub Copilot clients.

**Workaround** — a local stdio-to-HTTP shim that rewrites boolean subschemas to
`{}` before passing `tools/list` to the client. All 26 tools then register and
work correctly, which suggests the schemas are otherwise sound and only the
boolean encoding is at fault.

**Note** — third-party client setup per `docs/OtherClientSupport.md` works
correctly; `az ad sp create --id 22bfbae3-f4e7-485f-be43-8cee15065084` plus the
`MCP.Access` grant authenticates without issue. This report concerns only the
schema encoding.

**Trace ID** — not applicable. The server returns HTTP 200 with a well-formed
`tools/list` body; the failure is client-side schema validation, so no ARM MCP
trace ID is generated. For CDN-layer correlation, a representative successful
response carried `x-azure-ref: 20260807T015533Z-158dbd9cb64cbjswhC1CHIt9hs0000000dy0000000008324`.
Successful responses carry no `x-ms-request-id` or `traceparent`.

Start by reproducing the tools/list response with the PowerShell requests in the issue, then trace the server's tool-schema generation for the affected tools. Check docs/OtherClientSupport.md only for client context. Done means unconstrained result properties are emitted as schema objects rather than boolean true, and strict MCP clients register all tools.

Written by the indexing model from the issue text.