Clarify DATA delivery semantics with unclaimed HTTP/3 header sets

The multi-header-set work adds explicit notification for incoming HTTP/3 header sets via `on_hset_in`, allowing applications to call `lsquic_stream_get_hset()` when a header set arrives.

One related behavior question is whether an unclaimed HTTP/3 header set should block DATA delivery.

Current behavior to preserve for now:

- `read_data_frames()` may parse a HEADERS frame and continue processing subsequent DATA in the same read path.
- If the application does not claim a non-HTTP/1.x header set, existing `stream_readf()` behavior remains the primary guard when the queued hset is observed at the stream read layer.
- The multi-header-set implementation should not add a new filter-level rule that stops DATA solely because `stream->uh` contains an unclaimed HTTP/3 hset.

Question:

Should the public API define that DATA must not be delivered while an earlier HTTP/3 header set remains unclaimed, or should applications be responsible for claiming hsets promptly when `on_hset_in` fires?

If we choose the stricter behavior, it should be added deliberately with tests and API documentation because it can change existing header-bypass users that currently do not immediately drain 1xx/early-hints header sets.

Start by tracing read_data_frames() and stream_readf(), then review how on_hset_in and lsquic_stream_get_hset() expose queued HTTP/3 header sets. Resolve whether an unclaimed set should block DATA delivery or remain the application's responsibility. If stricter semantics are chosen, done requires corresponding tests and public API documentation.

Written by the indexing model from the issue text.