feat(http_server): expose tokenizer SHA256 on /get_model_info for parity verification

[DavidBellamy]

Summary

Add a `tokenizer_sha256` field to the `/get_model_info` endpoint that returns a deterministic hash of the active tokenizer's canonical JSON form. Lets clients verify two SGLang instances (or an SGLang instance and a separate trainer/embedding service) are using bit-identical tokenizers before relying on cross-process token-id assumptions.

Why

When token IDs cross process boundaries (e.g. an inference worker emits token IDs that another component uses as input to a separate process), the two sides must use bit-identical tokenizers — including merges, special tokens, and byte fallbacks. A subtle mismatch silently corrupts downstream logic in ways that are hard to diagnose because the IDs still look plausible.

Exposing a tokenizer hash on the existing model-info endpoint gives clients a one-call way to do this consistency check at startup.

Changes (`python/sglang/srt/entrypoints/http_server.py`)

• New `_compute_tokenizer_sha256()` helper that returns a SHA256 of `tokenizer.backend_tokenizer.to_str()` for HF fast tokenizers, or `None` if the active tokenizer doesn't expose that interface. Cached after first call.
• `/get_model_info` payload includes `tokenizer_sha256` next to the existing `tokenizer_path` field.

Behavior

• Field is optional (`None` when the tokenizer doesn't support `to_str()`); existing clients ignore unknown fields.
• One-time hash, cached.
• No new dependencies (stdlib `hashlib`).

Provenance

One of five focused PRs that supersede #3.