Plugin marketplace `marketplace.git` returns 404 on all git paths, though the plugin is registered and readable via the data API (eastus)

# Description

The plugin marketplace endpoint is enabled and a plugin is registered and fully readable through the data API, but the generated `marketplace.git` repository returns **404 on every git path** — so `git clone` / `/plugin marketplace add` cannot discover any refs. The repo appears to never be generated/served, even though the plugin exists.

This looks like the **same family** as #79 (data-plane 404 on the MCP `/v0.1/servers` endpoint, fixed "to all regions" on 2026-06-25) — but on the **plugin-marketplace** surface, which is still 404ing in **East US**.

# Environment

- API Center, region **East US** (`.data.eastus.azure-apicenter.ms`)
- Plugin marketplace endpoint: **enabled** (Data API settings)
- Portal access method: **Microsoft Entra ID**
- Inventory: 1 MCP server + 6 skills + 1 plugin bundling all 7
- Token used for tests: `aud=https://azure-apicenter.net`, `scp=Data.Read.All` (obtained via the managed-portal sign-in)

# Reproduction steps

1. Enable **Plugin marketplace endpoint** (Data API settings) with a registered plugin that bundles skills + an MCP server.
2. Acquire a valid `azure-apicenter.net` / `Data.Read.All` delegated token.
3. Confirm the plugin is readable via the data API (works — see below).
4. Request the marketplace git paths with the same token (over **HTTP/2** — see HTTP note):

```
GET …/workspaces/default/plugins/marketplace.git/info/refs?service=git-upload-pack -> 404
GET …/workspaces/default/plugins/marketplace.git/HEAD -> 404
GET …/workspaces/default/plugins/marketplace.git/.claude-plugin/marketplace.json -> 404
GET …/workspaces/default/plugins/marketplace.git -> 400 "The gitPath field is required."
GET …/workspaces/default/plugins -> 200 (returns the plugin)
```

# Expected behavior

`git clone …/marketplace.git` (and the `info/refs` discovery) returns the generated marketplace repo — `marketplace/` with `.claude-plugin/`, `.github/`, and a folder per plugin — as documented in *Enable Discovery of Plugins from API Center Plugin Marketplace*.

# Actual behavior

All git paths return **404** (`application/problem+json`), so `git clone` / `/plugin marketplace add` fails with "repository not found". The data API returns the plugin correctly, so the plugin is registered — the **git repo is simply not generated/served**.

Sample 404 body:
```json
{"type":"https://tools.ietf.org/html/rfc9110#section-15.5.5","title":"Not Found","status":404,"traceId":"00-455a74e4…"}
```

The data API returns the plugin fine (proving registration is correct):
```json
{"value":[{"name":"client-insights","version":"1.0.0","resources":[
{"resourceId":"/workspaces/default/skills/","kind":"skill"},
… 5 more skills …,
{"resourceId":"/workspaces/default/apis/","kind":"mcp"}]}]}
```

# traceIds (East US)

```
00-455a74e436d1…
00-4ffc7ae760d1…
00-f7160ce7122c…
00-fd4e3ffe362280b2d0b325d8507dc4be-7a0b988ebfd5bdac-00
```
(Subscription/tenant available on request.)

# What we already ruled out

- **Not auth** — 404 (not 401/403); the same token reads `…/plugins` with 200.
- **Not config** — endpoint enabled, plugin bundle complete (7 resources), visibility open, portal Entra access configured + published. Per the docs there is no separate publish/sync/RBAC/MCP-endpoint step.
- **Not transient** — reproduced repeatedly over ~1.5h with fresh tokens.
- **Toggle off→save→on→save** the marketplace endpoint: no effect (still 404).
- Persists **after** #79's fix landed.

# Secondary issue — authenticated HTTP/1.1 requests return empty-body 500

Independently: **authenticated requests over HTTP/1.1** (git's default, plus curl / PowerShell `Invoke-WebRequest` / python `urllib`) return an **empty-body 500 (no `x-ms-request-id`)** for *all* data-plane paths. The **same token over HTTP/2** returns correct codes (200 for `…/plugins`, 404 for the marketplace). Unauthenticated HTTP/1.1 cleanly 401s — it's the presence of an `Authorization` header over HTTP/1.1 that 500s.

This will block `git clone` even once the 404 is fixed (git negotiates HTTP/1.1 by default), so it's worth addressing alongside. Workaround: `git config http.version HTTP/2`.