feat(doctor): warn when an HTTP deployment silently disables H.264

[7174Andy]

Summary

lablink doctor now warns when the deployment will serve the viewer over plain HTTP,
because that silently disables H.264 video streaming.

Viewer streaming  WARN  ssl.provider is 'none', so the viewer is served over HTTP and
                        H.264 streaming cannot engage — sessions fall back to JPEG/WebP.
                        Configure an SSL provider, or to test as-is port-forward the
                        allocator (ssh -L 8443:localhost:5000 ...) and open
                        http://localhost:8443, since localhost counts as a secure origin

Chrome exposes the WebCodecs VideoDecoder only on secure origins, so on http:// the
viewer's codec probe reports WebCodecs API not available and negotiation falls back to
JPEG/WebP stills — re-encoding damaged regions from scratch every frame instead of
encoding inter-frame change. The server side is fine: -videoCodec auto makes KasmVNC
advertise H.264 and the encoder works. The browser declines it.

Why a check rather than more docs

It is documented — docs/configuration.md:313 and docs/architecture.md:254, under SSL
and streaming. But nothing in the deploy path says it, so the H.264 work in #477/#478 does
nothing for any domain-less deployment and there was no way to find that out short of
reading the browser console. What reaches an operator is "the desktop feels laggy", which
is a long way from "ssl.provider is none".

Found while diagnosing a real IP-only deployment where exactly this was happening.

Behaviour

ssl.provider	Result
none, or unset	warn — names the fallback and the port-forward that makes H.264 testable without a domain
letsencrypt, cloudflare, acm	pass — viewer served over HTTPS
no valid config	warn (skipped), matching the other checks

warn, not fail. HTTP is a supported deployment, just a slower one; failing preflight
over a performance cliff would block a legitimate config. One of the tests asserts that
explicitly, so a later edit can't quietly promote it to a failure.

Testing

packages/cli: 829 passed, 1 deselected
ruff check packages/cli: All checks passed!

Six new cases: HTTP warns and names the workaround, the three HTTPS providers pass, a
missing ssl section is treated as HTTP, and the warn-not-fail contract is pinned.

Related

• feat: KasmVNC 1.5.0 with H.264 video streaming (NVENC-capable) #477, fix(allocator+client): stop the viewer's 20-min idle kill and let H.264 streaming engage #478 — the H.264 / NVENC work this makes discoverable. fix(allocator+client): stop the viewer's 20-min idle kill and let H.264 streaming engage #478's own description still
  leaves NVENC unverified on a native-Linux GPU VM (it was validated on WSL2, which fell
  back to software x264); the port-forward in this message is what makes that testable on
  an IP-only deployment.
• docs+doctor: say that an HTTP deployment disables H.264 streaming lablink-template#72 — the same warning in the template, at the four places a
  Path B operator actually chooses HTTP. Path B users never run lablink doctor, so both
  are needed.