http2: a pseudo-header in trailers, or repeated in a block, replaces the request's, so a handler can see another path #503

What happens

PendingRequest.AddHeader stores whatever pseudo-header it decodes into the request's Method, Path, Scheme or Authority, with no check of where it appeared. So on a buffered request:

• In trailers: :path in a trailer block replaces the request's path.
• Repeated in one block: the last :path wins.

The handler sees the replaced value, and nothing tells it the request was malformed. RFC 9113 8.1 forbids pseudo-headers in trailers, and 8.3 forbids repeating one in a block; both make the request malformed, a stream error.

Reach

It matters behind anything that decides from the first value and forwards the frames: a proxy that authorizes /public while the handler here serves /admin.

Repro

Unit, over the hand-driven test peer, on main 58620b5:

• POST /public, some DATA, then trailers with :path: /admin and END_STREAM: the handler sees /admin.
• POST /public with a second :path: /admin in the same block: the handler sees /admin.

Neither gets an RST_STREAM or a GOAWAY.

Fix

Treat these as malformed and reset the stream with PROTOCOL_ERROR, once the block is decoded so HPACK stays in step: a pseudo-header in trailers, a repeated one, and one after a regular field (RFC 9113 8.3). #500 lets trailers split over CONTINUATION reach the same code, so the check belongs in the decode rather than in the frame handler.

The nghttp2 stack does not have this: nghttp2_http_on_header rejects such a field in the library, by reading its source.

Found by a review of #500.