fix(spanner): export built-in metrics per project - #18750

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #18155 🦕

Description

When a process creates Spanner clients for more than one GCP project, built-in client metrics are exported through a single CloudMonitoringMetricsExporter. That exporter previously sent every time series in one CreateTimeSeries request named projects/<first-client-project>. Cloud Monitoring then rejects the batch with 400 because resource.labels.project_id does not match the request name, so neither project receives metrics.

This change groups time series by resource.labels.project_id and issues one CreateTimeSeries request per project (name=projects/<id>), still batched at 200 series. Series without a resource project label keep falling back to the exporter's configured project. Client wiring is unchanged: each client's metric points already carry their own project_id.

This PR does not add a custom exporter or meter-provider hook.

Testing

• Regression: test_export_groups_time_series_by_project_id exports points for project-a and project-b via a mock MetricServiceClient and asserts two requests, each named projects/<id> with matching series.
• On main the test failed (AssertionError: 1 != 2). After the grouping fix it passed.
• Nearby metrics unit tests: 117 passed.
• Lint on the touched files: ruff check / ruff format --check / flake8 clean. Package nox -s lint was not practical here (session requires Python 3.14).

This change was prepared with AI assistance and reviewed by the author.