Sidecar metrics collection over plugin gRPC has no deadline — one stuck operation hangs the whole instance /metrics

## Environment

CloudNativePG 1.30.0, plugin-barman-cloud v0.14.0, PostgreSQL 17/18 clusters, VersityGW (posix) S3 endpoint.

## What happens

The instance sidecar collects plugin metrics over the plugin gRPC with **no deadline on the collect path**. Consequence: if any plugin operation gets stuck (in my case a retention/catalog-maintenance run that never completes against a posix-backend S3 gateway — filed separately), the next scrape blocks on the collector and the **entire** `/metrics` endpoint of that instance hangs indefinitely. Prometheus marks the target down and every metric of that instance disappears, not just the plugin's own collectors.

Observed in production: the primary instance's exporter dark for 6.7 hours while the database itself was healthy — WAL-archiver and backup-staleness alerting was blind precisely on the instance where it matters.

## Expected

- A per-collect deadline (a few seconds) on the plugin metrics gRPC call.
- On timeout/error: return the rest of the metrics plus an error counter (e.g. `..._collector_errors_total`), instead of hanging the whole endpoint. A misbehaving plugin should degrade its own metrics, never the instance's.

## Reproduction sketch

1. ObjectStore against VersityGW (posix backend) with any `retentionPolicy` set.
2. Wait for a retention run to start (~30 min cadence) — it never completes against this backend.
3. Scrape the instance sidecar's metrics port: the request hangs until the client gives up; `up` goes to 0 for the instance.

Companion issue describes the retention hang itself; this one is about the missing deadline that turns any such hang into a full metrics outage.

インスタンス sidecar の plugin gRPC メトリクスの collect パスを追跡し、plugin の処理が停止した状態で問題を再現してから、/metrics エンドポイントが collector のエラーをどのように処理するかを調べます。collect ごとのタイムアウトによって、plugin 呼び出しが停止した場合でもエンドポイントが残りのメトリクスを返し、エラーを記録できることを確認します。また、正常な plugin メトリクスが引き続き機能することも確認します。

索引モデルが issue の本文から書いたものです。