v0.13.2 — Merchant Center feed health

Merchant Center feed health actually returns data

get_merchant_feed_health has never worked against a real Merchant Center
account. It answered Merchant API returned 404: with an empty message, which
reads like an account problem: no products, no data source, no API access. It
was none of those.

The Merchant API is not one flat surface. It is a set of independently
versioned sub-APIs whose name is part of the request path, and AdLoop sent
every call to accounts/v1. That is right for listing accounts, reading
account issues and developer registration, but product-status aggregation
lives under issueresolution/v1. Google answers a path that does not exist
with a bare 404 and no error text, so the failure gave nothing to go on.

• aggregateProductStatuses now goes to issueresolution/v1, checked against
  Google's live Discovery documents rather than recalled from prose docs.
• Every Merchant call states its own sub-API, so adding datasources or
  reports calls later is a keyword instead of a second hardcoded base.
• Non-200 responses now name the URL that failed. A status code with no
  message is what made this one expensive to find.
• New tests pin the full URL for each endpoint and drive feed health end to
  end with only the transport faked. Every previous test mocked the request
  layer, and the one assertion that touched a URL matched on its tail, so
  nothing ever checked the URL the client builds.

Same content scope as before: nothing to reconnect, re-consent, or
re-verify. On AdLoop Cloud the fix is already live.

Installs cleanly on fastmcp 4

One test reached into mcp.shared.session, which mcp 2 removed, and that took
down collection for the entire suite on a fresh install. The runtime already
treated the module's absence as "nothing to patch", so this was only ever a
test problem, and no dependency cap was needed. The suite now passes on both
fastmcp 3 with mcp 1 and fastmcp 4 with mcp 2.

About 0.13.1

0.13.1 was tagged and never published: its release run failed on the
collection error above, before reaching PyPI. 0.13.2 is that same release plus
the fix that let it out.