All 9 testable launch scripts in examples/backends/sglang/launch/ pass on
0.5.11 with no handler/init code changes. (disagg_router needs 4 GPUs and
multimodal_disagg needs 3 GPUs; both skipped on the test box's 2x L40S.)

The new support window is N=0.5.11, N-1=0.5.10, so the 0.5.9-targeted
branches in _compat.py come out as part of this bump per the
N/N-1 policy in components/src/dynamo/sglang/CLAUDE.md.

Removed:
* `NetworkAddress` polyfill class + `try/except` around its import
  (`sglang.srt.utils.network` is canonical from 0.5.10 onward).
* `mm_encode()` wrapper. Both 0.5.10 and 0.5.11 take
  `_encode(mm_items, modality)` and return the same 3-tuple, so the
  call sites in `encode_worker_handler.py` now invoke
  `await self.encoder._encode(...)` directly.
* `enable_disjoint_streaming_output` `stream_output` fallback. The
  field has been `incremental_streaming_output` since at-or-before
  0.5.10 (verified: `ServerArgs.__dataclass_fields__` in 0.5.11 has
  `incremental_streaming_output` and not `stream_output`). The
  wrapper itself stays — diffusion `SimpleNamespace` stubs need the
  attribute-absent no-op path.

Kept (not version-bound):
* `ensure_sglang_top_level_exports()`, `filter_supported_async_generate_kwargs`,
  `get_scheduler_info` (the latter still probes fork/experimental
  attribute paths).

CLAUDE.md example version bumped to reflect 0.5.10 as the new N-1.

Closes #8151 (now unblocked: sgl-project/sglang#22726 landed in v0.5.11,
which is the new floor after this PR).

Adds a "KV Pool Detail" row to deploy/observability/grafana_dashboards/sglang.json
with two new panels driven by the gauges added in 0.5.11:

* `KV Pool Breakdown (tokens)` — stacked timeseries of
  `sglang:kv_used_tokens` (locked by running requests),
  `sglang:kv_evictable_tokens` (radix-cached, reclaimable), and
  `sglang:kv_available_tokens` (free). The three series sum to
  <= `sglang:max_total_num_tokens` per the invariant documented in
  SGLang's metrics_collector.py.

* `KV Pool Physical Usage %` — `(1 - kv_available / (kv_available +
  kv_evictable + kv_used)) * 100`. Captures true pool occupancy
  including evictable slots, vs. `sglang:token_usage` which excludes
  them. 90% threshold drawn in red for the "no headroom even after
  evict" case.

The existing `GPU KV Cache Usage %` panel (driven by
`sglang:token_usage`) is unchanged — it's still useful as the
"bottleneck across full / SWA / mamba pools" view that the new
gauges don't replicate.

Verified live on a Qwen/Qwen3-0.6B agg worker: all three gauges
export at `<system_port>/metrics`, and `kv_available + kv_evictable
+ kv_used` = `max_total_num_tokens` after a real request.

`tests/report_pytest_markers.py` mocks sglang submodules so test collection
succeeds in the pre-commit isolated venv (which doesn't install sglang).
Now that `dynamo.sglang._compat` imports from `sglang.srt.utils.network`
unconditionally (the 0.5.9 fallback was pruned in the same PR), the
mock list needs that submodule too — otherwise marker reporting fails
to collect any sglang test file.

Now that the 0.5.9 fallback for `NetworkAddress` is gone, the
re-exports in `_compat` are pure pass-throughs of
`sglang.srt.utils.network.{NetworkAddress,get_local_ip_auto,
get_zmq_socket}`. Per the policy in `components/src/dynamo/sglang/CLAUDE.md`,
trivial re-exports belong at call sites, not in `_compat` — the shim
is reserved for symbols that have actually broken across versions.

Move the three imports to:
- `register.py`             (NetworkAddress, get_local_ip_auto)
- `publisher.py`            (NetworkAddress, get_local_ip_auto, get_zmq_socket)
- `request_handlers/handler_base.py` (NetworkAddress, get_local_ip_auto)

`_compat.py` keeps `ensure_sglang_top_level_exports`,
`filter_supported_async_generate_kwargs`, `get_scheduler_info`, and
`enable_disjoint_streaming_output` — all of which are still doing
real version-bridging work (signature probing, multi-attribute
fallbacks, SimpleNamespace stub handling).

Per @dynamo-ops review on #9230: dividing by
(kv_available + kv_evictable + kv_used) inflates the percentage when
internally protected slots are present, since the SGLang invariant is
`available + evictable + used <= max_total_num_tokens` (note <=, not ==).
Using `sglang:max_total_num_tokens` as the divisor gives true pool
occupancy regardless of how slots are accounted internally.

Expression:
  before: (1 - kv_available / (kv_available + kv_evictable + kv_used)) * 100
  after:  (1 - kv_available / max_total_num_tokens) * 100

Also rewrote the panel description so it reflects the new framing
("not free, normalized against max_total_num_tokens") rather than the
incorrect "physically allocated (used + evictable)" wording, and called
out what `sglang:token_usage` actually measures (bottleneck across
full/SWA/mamba pools) for clearer reviewer context.

Bumps `lmsysorg/sglang:v0.5.10.post1-runtime` →
`lmsysorg/sglang:v0.5.11-runtime` (and the `-cu130-runtime` variant)
across:
- container/context.yaml
- container/compliance/README.md

Verified the tags resolve on Docker Hub:
  digest sha256:6f81caf1d2a24b2cfc212410900c14d633302bc16e6ec8379c0d382e625ab313

These were published by sgl-project/sglang's `Release Docker Runtime
Images` workflow run https://github.com/sgl-project/sglang/actions/runs/25470428234
(workflow_dispatch from main with version=0.5.11). The workflow uses
the dispatched ref's Dockerfile, so main's already-fixed Dockerfile
(sgl-project/sglang#24234) builds against v0.5.11 source — no need
to wait for that fix to be cherry-picked into release/v0.5.11.

Also drop the libjsoncpp25 apt workaround from
container/templates/sglang_runtime.Dockerfile. v0.5.11's runtime image
bundles libjsoncpp inside the mooncake wheel itself
(/usr/local/lib/python3.12/dist-packages/mooncake_transfer_engine_cuda13.libs/
libjsoncpp-7d699962.so.1.9.5), so `from mooncake.engine import
TransferEngine` now succeeds without the system-level package. Verified
via `docker run --rm --runtime=runc --entrypoint bash
lmsysorg/sglang:v0.5.11-runtime -c 'python3 -c "from mooncake.engine
import TransferEngine"'`.

…nt hang

SGLang 0.5.11 silently hangs requests when prompt+max_tokens nears
max_total_tokens (no scheduler activity, no error). Bisected threshold
is ~1040 for the chat_payload_default() case (~16-token prompt +
max_tokens=1000); KV=1024 hangs, KV=1040 works (truncated to 962
tokens), KV=1056+ works fully. Test was at KV=96, well below threshold.

The real fix for the aggregated test hangs was the KV budget bump
(d27b271), not the pytest timeout. Revert to the original profiled
value.

The dynamo, sglang, and kvbm dashboards reference prometheus uid
P1809F7CD0C75ACF3, which doesn't match the provisioned uid `prometheus`,
causing "datasource not found" panels. Add a second provisioned entry
pointing at the same prometheus URL with the legacy uid so both groups
of dashboards resolve cleanly.

… under Router

- Inflight vs Queued: explain the difference (inflight = dispatched, awaiting
  completion; queued = received but not yet dispatched). The combined shape
  is the steady-state diagnostic — flat inflight + growing queue means
  workers are saturated.
- Pool Utilization panel: drop the redundant "overall (legacy)" series. On
  non-hybrid models it duplicates full_token_usage and adds noise; on
  hybrid models its semantics overlap with the dominant pool. Spell out
  what each remaining series (full / SWA / Mamba) means in the description.
- Move Per-Worker Detail row to sit directly under the Router row, since
  per-worker fanout is conceptually a drill-down of routing distribution.

Speculative decoding accept rate / accept length are throughput-level
signals (they directly explain tokens-per-step), not disagg-queue signals.
Move them out of the disagg row and into "SGLang Engine — throughput &
batching" as two side-by-side panels with explanations of when they
populate. Disagg row keeps just the grammar queue.

Restructure _test_agg.sh from single-worker to two-worker behind a
KV-aware router, matching agg_router.sh's topology:

  - frontend with --router-mode kv (KV events on by default, --approx
    falls back to approximate routing without KV events)
  - 2 SGLang workers, one per GPU (CUDA_VISIBLE_DEVICES=0,1)
  - per-worker DYN_SYSTEM_PORT (8081, 8082) and per-worker ZMQ KV-events
    endpoints (5557, 5558)
  - all 0.5.11 observability features still on for both workers

Update prometheus scrape config to pick up both worker metric ports;
without 8082 in the dynamo-backend job target list, Grafana would only
show worker 1 in the Per-Worker rows.