Indeed, this is not possible. Views currently only have local data configuration on them.
But regardless of the forwarder issue where you want it enabled/disabled based on view (which is not possible as I replied on the other topic, there are more issues with caching and queries in flight.
There is a single global cache in Unbound, if something is found there adguard will not be contacted to begin with, not sure if this is desired or not.
There would be a weird cyclic dependency on a single query that passes through adguard, for a hypothetical example with a single Unbound for the same query:
client -> unbound -> adguard
adguard -> unbound -> maybe internet?
Unbound would get the incoming query from adguard and see that the same query is already under resolution (from the client) and aggregate the two together. So the second query would wait for the first to complete.
When/If the query would have been resolved, Unbound would reply to both the client and the adguard since the tuple (qname, type, class) would be the same as I understand it. Not a desired behavior as I understand it.
Having two separate Unbounds with clearly distinct roles is the better solution here in my opinion. Also troubleshooting-wise.
There are talks to incorporate more functionality in views but this is something for the future and not a trivial feature request which touches a lot of functionality.