Default headers work around

[itsibitzi]

A work around for an outstanding issue where HTTP client doesn't copy the default headers across.

We need to decide long term if we want to have a different approach for HTTP and direct or you just pass in a HTTP client to a direct to give default headers.

It does feel a bit weird to pass in a HTTP client to a direct TwirpClient, but we have one already.

Right now there are some runtime panics if you use the wrong methods on the builder (e.g. if you try to add a handler to a http client). We could get around this by adding a marker type to be builder and only implementing direct mode functions on e.g. ClientBuilder<DirectMode>

[Copilot]

Pull Request Overview

This PR implements a workaround for an issue where HTTP clients don't copy default headers across requests in Twirp client configurations. The change adds support for setting default headers in direct mode and ensures they are properly applied to requests.

Key changes:

• Added with_default_header method to ClientBuilder for setting default headers in direct mode
• Modified request execution to apply default headers when they don't already exist on the request
• Refactored ClientBuilder to use struct spread syntax for cleaner code

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The error message mentions 'handler headers' but the method is for 'default headers'. Consider changing to 'you must use ClientBuilder::direct() to register default headers'.

Suggested change

	panic!("you must use `ClientBuilder::direct()` to register handler headers");
	panic!("you must use `ClientBuilder::direct()` to register default headers");

[Copilot]

Using panic! for API misuse creates a poor developer experience. Consider returning a Result or using a builder pattern with marker types to prevent this at compile time, as mentioned in the PR description.

[aneubeck]

makes sense to me