Consider admission control for Guest Agent RPCs

## Problem

VMM proxies several API methods to the Guest Agent over vsock. Request deadlines bound how long each individual call can remain active, but they do not cap the number of calls that can execute concurrently. A burst of requests, or many unresponsive guests, could therefore create a large number of concurrent connection attempts and request tasks until their deadlines expire.

## Possible approach

Consider adding admission control at the centralized Guest Agent client boundary, with:

- a global VMM concurrency limit;
- an optional per-VM concurrency limit so one guest cannot consume the full budget;
- explicit overload behavior (fail fast versus bounded queueing);
- metrics for active calls, rejected calls, and timeout rates;
- limits derived from expected deployment size and measured resource use rather than hard-coded without capacity data.

This is intentionally tracked separately from request timeout hardening so the timeout fix remains small and the operational policy can be reviewed independently.

Aucun fichier, test ou point d’entrée n’est nommé. Commencez par localiser la frontière centralisée du client Guest Agent et examiner comment les appels RPC de VMM, les deadlines et les métriques sont actuellement gérés. Définissez la politique de concurrence et de surcharge à partir de la capacité de déploiement et de l’utilisation mesurée des ressources ; la tâche est terminée lorsqu’un design approuvé couvrant les limites globales et par VM, le comportement en cas de surcharge et les métriques est défini.

Rédigé par le modèle d'indexation à partir du texte de l'issue.