google-ads: support per-request login_customer_id for multi-MCC access

[ctrlswing]

Problem

login_customer_id is hardcoded from GOOGLE_ADS_LOGIN_CUSTOMER_ID at server startup (auth.js:72). This means a single MCP server instance can only access accounts under one MCC hierarchy.

Users managing accounts across multiple MCCs (e.g. an owned MCC + a partner/affiliate MCC) must either:

1. Run duplicate server instances with different env vars — doubling tool namespaces and config overhead
2. Restart the server with a different env var to switch MCCs

Neither is practical. The Google Ads API itself supports passing login_customer_id per-request via the google-ads-api Node client — the server just doesn't expose it.

Current behavior

// auth.js — login_customer_id is always read from env
export function getCustomerClient(customerId) {
  const client = initializeGoogleAdsClient();
  return client.Customer({
    customer_id: customerId,
    refresh_token: process.env.GOOGLE_ADS_REFRESH_TOKEN,
    login_customer_id: process.env.GOOGLE_ADS_LOGIN_CUSTOMER_ID,  // ← fixed at startup
  });
}

The query and mutate tools accept customer_id to target a sub-account, but there's no way to specify which MCC to authenticate through. list_accounts has the same limitation — it always lists accounts under the startup MCC.

Proposed change

Add an optional login_customer_id parameter to query, mutate, and list_accounts. When provided, it overrides the env var for that request. When omitted, behavior is unchanged (falls back to GOOGLE_ADS_LOGIN_CUSTOMER_ID).

auth.js — accept override:

export function getCustomerClient(customerId, loginCustomerId) {
  const client = initializeGoogleAdsClient();
  return client.Customer({
    customer_id: customerId,
    refresh_token: process.env.GOOGLE_ADS_REFRESH_TOKEN,
    login_customer_id: loginCustomerId || process.env.GOOGLE_ADS_LOGIN_CUSTOMER_ID,
  });
}

Tool schemas — add optional parameter:

"login_customer_id": {
  "type": "string",
  "description": "MCC account ID to authenticate through (overrides GOOGLE_ADS_LOGIN_CUSTOMER_ID env var)"
}

Impact

• Backward compatible — existing users see no change; the parameter is optional with the same default
• Small surface area — touches auth.js (1 line), plus parameter threading in 3 tool files
• Matches the Google Ads API design — login_customer_id is a per-request header in the REST API (login-customer-id), so exposing it per-call aligns with upstream behavior

Use case

Managing a portfolio across two MCCs (72 accounts under one, additional accounts under a partner MCC) from a single MCP server instance, without needing duplicate server configs.