Expose complete scoped AgentOS limit usage for observability

まず VmLimits と QueueRegistry を監査し、次に TypeScript core、Rust client、actor package にある既存の NodeRuntime.getResourceSnapshot() の transport と AgentOs API を追跡します。各 limit をその descriptor と usage source に対応付け、その後 acceptance criteria を使って、完全な結果、認可されたスコープ、audit coverage、parity、および複数 VM 間の leakage テストを検証します。

Problem

AgentOS has two centralized limit mechanisms today:

• VmLimits is the authoritative sidecar-owned configuration and enforcement surface.
• QueueRegistry tracks live usage for manually registered gauges and produces depth, high_water, capacity, and fill_percent snapshots.

The existing get_resource_snapshot path exposes the registered gauges, but it does not represent every configured limit. The registry currently covers selected queues, kernel resources, V8 budgets, and WASM budgets. There is no automatic descriptor/catalog connection between a VmLimits field and its observable usage.

The snapshot also reads from a process-global registry whose entries do not carry scope or VM identity. A VM-addressed request therefore cannot reliably distinguish VM-local gauges from sidecar-wide gauges when a sidecar hosts multiple VMs.

Missing measurable usage

Audit and register live usage where it is meaningful, including at least:

• ACP sessions, prompts, retained history bytes/events, and pending permissions
• JavaScript timers
• reactor capabilities, ready handles, tasks, bridge calls, async completions, and blocking jobs/bytes
• UDP buffered datagrams/bytes
• TLS buffered bytes
• HTTP/2 connections, streams, pending commands/events, and buffered/header/data bytes
• any other count/byte limit with durable current usage that is enforced through VmLimits

Non-gauge limits

Some configured limits do not have meaningful persistent usage, including per-operation payload caps, page sizes, work quanta, and inactive deadlines. These should still appear in an authoritative limit catalog with their configured capacity and measurement semantics, while reporting live usage as unavailable rather than inventing a percentage.

Example shape:

interface LimitUsage {
  name: string;
  configurationPath: string;
  category: "queue" | "resource" | "memory" | "cpu" | "deadline" | "payload";
  scope: "sidecar" | "vm" | "session" | "process" | "capability" | "connection" | "stream";
  unit: "items" | "bytes" | "milliseconds" | "tasks" | "connections" | "streams";
  capacity: number;
  currentUsage: number | null;
  highWater: number | null;
  fillPercent: number | null;
  measurement: "gauge" | "per_operation" | "deadline" | "quantum";
}

The exact wire shape can differ, but the sidecar must remain the single source of truth.

Scope and security

• Associate registered gauges with their owning scope and VM where applicable.
• A VM-scoped snapshot must not expose another VM's usage or identities.
• Sidecar-wide aggregate usage should be available only through an explicitly host-authorized observability surface.
• Preserve the design requirement that guest-visible diagnostics cannot become a cross-tenant occupancy oracle.

Public API

Expose the resulting snapshot with behavioral parity across:

• AgentOs.getResourceSnapshot() in @rivet-dev/agentos-core
• the Rust AgentOs client
• a getResourceSnapshot action in @rivet-dev/agentos

@rivet-dev/agentos-runtime-core already has the lower-level transport and NodeRuntime.getResourceSnapshot() implementation; product users should not need to depend on that implementation package directly.

Acceptance criteria

• Every VmLimits field has one canonical runtime descriptor containing its configuration path, category, unit, scope, and measurement semantics.
• Every meaningfully measurable count/byte/budget limit is connected to live usage and high-water accounting.
• Non-gauge limits are returned with configured values and nullable usage/percentage.
• VM-addressed snapshots contain only that VM's data plus explicitly labeled, authorized sidecar aggregates.
• TypeScript core, Rust client, and actor APIs expose equivalent JSON-serializable results.
• The limits audit fails when a new operator-facing limit lacks a descriptor, and fails when a measurable limit lacks accounting.
• Tests cover multiple VMs in one shared sidecar and prove there is no cross-VM leakage.
• Resource-limit documentation is updated to distinguish configured limits, measurable gauges, and non-gauge enforcement limits.

This enables an inspector page to render the complete limit inventory directly from the API without maintaining a separate UI mapping.