First of all, there is no reason that for any generic type T and trait Trait, T<U: Trait> should in general be convertible to T<dyn Trait>.
Wrapping a single other item of type U is not all a generic container can do. What if there are multiple instances of the type, for example? How would you create a Vec<dyn Trait> in a reasonably cheap and efficient manner, given that its memory buffer needs to be contiguous, but the type dyn Trait is dynamically-sized?
It therefore seems logical that the ability for such a conversion should be opt-in. With that said, unsizing coercions are a somewhat magic and definitely unstable feature. If you are willing to use the nightly compiler, you can implement the CoerceUnsized trait to achieve this effect.
The thing you want to do is called unsizing coercion and is mostly a compiler built-in. For generic types, this is largely controlled by the CoerceUnsized trait. You can find an impl for Box<T> in the source.
CoerceUnsized is currently unstable, so you can't do what you want. If the dynamically sized types ever become stable, this functionality is expected to also be stabilized.
But what is idiomatic way to have a Vec of Container of different types?
If I have Vec<Container<dyn Pet>> and Container<Dog> I can't even add it to the vec
You seem to be trying to simulate inheritance from object-oriented languages. That in itself is already not idiomatic in Rust.
Overall, this feels like an XY problem. Instead of giving us a toy example, ask about what you are trying to accomplish in reality, then we can tell you more easily how you should likely approach the problem.
This does sound likely to be an unfitting Object-Oriented pattern, but, if this is done, the idiomatic way typically would be to define an enum with the possible contained types as fields on different variants.