Gang of Four sums up the difference between Template Method and Strategy as follows:
Template methods use inheritance to vary part of an algorithm. Strategies use delegation to vary the entire algorithm.
What are the scenarios where combining two designs would be justified and how their relationship would look like?
Trivial example would involve delegating to Strategy inside hook methods of a Template Method, however, I cannot think of a good justification for such design. Additionally, instead of delegating to subclass one might delegate to Strategy directly. But then, without inheritance, we cannot talk about Template Method at all.
I think that it's perfectly possible to combine both patterns.
You use the Strategy pattern when you want to change a certain behavior at run time, simply changing the instance of the strategy.
I.e., you can change the behavior of the instances of "Context" by assigning "strategy" to a different concrete Strategy class. It provides the same functionality than having a field that you can change and doing a chain of if/elses or a switch based on the content of this field. The strategy pattern simply a more sophisticated way to do conditional. The advantage of using the strategy over a hard coded conditional is that you can put more conditions by adding new classes, without having to modify existent ones (the "O" in the "SOLID" principle).
The template method, by other hand, defines an algorithm that has some "hooks" left open, that must be overwritten by concrete class.
Both patterns are concerned about an algorithm by two different point of views: strategy about the ability of exchanging an algorithm at runtime, and template method about flexibilizing the structure of an algorithm. I don't see why you can't combine both. For me it's perfectly possible to have a strategy that is defined as a template method.