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.

No files, tests, or entry points are named. Start by locating the centralized Guest Agent client boundary and reviewing how VMM RPC calls, deadlines, and metrics are currently handled. Define the concurrency and overload policy from deployment capacity and measured resource use; done requires an agreed design covering global and per-VM limits, overload behavior, and metrics.

Written by the indexing model from the issue text.