Is passing the tenant in a custom HTTP header RESTful?

If you needed the tenant ID to identify the resource, then the RESTful way would be to have it in the URL. If you don't (id is unique across tenants) then technically, you don't need it in the URL or the header.

Since id is unique across all tenants then /foos/{id} can uniquely identify that resource and is RESTful.

I would avoid using custom headers as a way of addressing a resource. They should be used instead to pass ancillary information like accept types, auth tokens, etc... You need to decide whether it's critical to identify the resource and put it in the URL or not.

The URI should uniquely identify the resource.

But this is orthogonal to authorization and access. Two people could ask for the same resource. One gets nothing, an elided copy, or an error; whereas the other would get the whole thing because they are properly identified in the Authorization header.

Now the URI can include the tenant id as part of its unique URI, there's nothing wrong with that. But either way, the resource itself will (somehow, including by a component of its URI or an internal state) "know" to which tenant it belongs.

So, in your case you should be using the HTTP Authorization header to properly identify the requester and then use that information to determine internally whether and what the response will be for a specific request. A requester may be authorized to see none, one, some or all tenants on a system.

You shouldn't need a custom header at all for this use case.