Auth callbacks cannot open streams

`quic_dist_auth` documented opening a user stream for a challenge/response. That never worked, and the docs have been corrected in #278 to say so. The underlying problem is stream numbering.

Stream ids are assigned in the order streams are opened, and both sides assume the dist control stream is stream 0 with the 16 data streams immediately after it (`quic_dist_controller:setup_streams/1` hardcodes `control_stream = 0` for the server). A client callback runs before the controller exists, so its stream takes id 0 and the control stream shifts to 4, with the last data stream landing on `?USER_STREAM_THRESHOLD_CLIENT`. A server callback's stream takes id 1, below `?USER_STREAM_THRESHOLD_SERVER`, so `is_user_stream/2` says false and its inbound data is fed to the distribution input handler.

Fixing it means allocating the auth stream through the controller, or reserving an id range for it, so the classifier on both sides still agrees. Until then the hook is for connection-level checks: peer certificate, ALPN, transport parameters, PSK identity.

Start with quic_dist_controller:setup_streams/1 and inspect its hardcoded control stream and the ?USER_STREAM_THRESHOLD_CLIENT, ?USER_STREAM_THRESHOLD_SERVER, and is_user_stream/2 logic. Trace how auth callbacks open streams before the controller exists; done means callback streams are allocated or reserved so both peers classify them consistently and their data does not reach the distribution input handler.

Written by the indexing model from the issue text.