grill-perf: optional provider metrics snapshot per wave (vLLM /metrics)

[plotarmordev]

Problem

For speculative-decoding servers the acceptance rate is the whole story (structured vs prose on GLM differs 3x because of DFlash2 accept length), but the client cannot see it. Nightshift already scrapes vllm:spec_decode_num_draft_tokens_total / _accepted_tokens_total and the running/waiting gauges around each measurement.

Proposal

--metrics-url URL (loopback/HTTPS rules as for the endpoint): snapshot a fixed allowlist of counters before and after each wave into wave.json as provider_metrics: {before, after}; never used for eligibility; absence stays null. The running/waiting gauges also give a quiescence check before dispatch.

[plotarmordev]

Resolved in PR #23. --metrics-url now captures bounded before/after snapshots with a fixed selected-series allowlist, immutable configuration, hash-bound companions, whole-run budgets and offline diagnostics. Missing/reset/inconsistent counters do not yield an acceptance ratio. There is no automatic idle gate, model-auth forwarding, redirect/retry or performance-eligibility change. Independent SIX and HELP reviews found three defects; real-CLI regressions failed before fixes and passed afterward. Final integrated suite: 153 passed, 1 ignored; exact-head CI green. Actual CLI loopback exercised model collection plus metrics scraping. No live provider/model request was made: metric availability and workload attribution on a real shared server remain unqualified. Raw labels/comments remain private evidence unless separately reviewed.