As I read fetch-http2.ts (and based upon bug reports received in an application that uses fetch-h2), at line 240 it raises an error if it receives a HEADERS frame after the initial request header section is consumed (i.e., a non-final response):

stream.on( "headers", guard(
	( headers: IncomingHttp2Headers, _flags: any ) =>
	{
		const code = headers[ HTTP2_HEADER_STATUS ];
		reject( new Error(
			`Request failed with a ${code} status. ` +
			"Any 1xx error is unexpected to fetch() and " +
			"shouldn't happen." ) );
	}
) );

The HTTP specification is pretty clear about this:

A client must be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent may ignore unexpected 1xx responses.

Accordingly, the Fetch specification instructs implementations to ignore them (step 7.3):

Any responses whose status is in the range 100 to 199, inclusive, and is not 101, are to be ignored.

Not following these requirements will cause interoperability problems, because the client can't control what the server sends. For example, it causes fetch-h2 to fail when Early Hints are in use.

I think the fix is to just remove the code above.