Live burn rate, session cost so far, and org runway for a VM

Host-side NVIDIA telemetry for a pod's GPUs, sampled on the node that runs it and returned as one continuous time grid. Every series and every GPU in a response shares that grid: the value at index i of any values array was measured at start plus i times stepSeconds, and a null means the node reported no sample at that point. The window ends now and covers only the periods this pod actually held the GPUs it is reported against, so a card that ran another customer's pod earlier never contributes a sample here. A GPU attached to a VM is passed through to the guest, so the host cannot read it. That case answers 200 with an accelerator status of unavailable and an empty gpus list rather than an error, and so do a pod that has not started yet, a pod that was not running in the selected range, and a metrics store that cannot be reached: the accelerator object is the answer, and the client renders its detail sentence. A host that stopped reporting while the pod is still running answers degraded with the history up to the last sample still attached. This operation is exposed as an agent tool by default, in the same class as a pod's burn rate: "how busy were my GPUs" is a read-only question about a resource the caller already owns.