Known issues with VNT, part 2 -- type stability when overwriting deeply nested values

This is not type stable (at least on 1.11):

using DynamicPPL, Test, BangBang
using DynamicPPL: templated_setindex!!

e = (; f=fill((; h=zeros(2)), 3))
vn = @varname(e.f[3].h[2])
# This call is type stable.
vnt = @inferred(templated_setindex!!(VarNamedTuple(), 1.0, vn, e))

# Both calls are type unstable.
vnt1 = @inferred(setindex!!(deepcopy(vnt), 2.0, vn))
vnt2 = @inferred(templated_setindex!!(deepcopy(vnt), 2.0, vn, e))

Note that they do give the correct result, so there is no question of correctness, it's just performance.

vnt1 = setindex!!(deepcopy(vnt), 2.0, vn)
vnt1[vn] == 2.0 # true

vnt2 = templated_setindex!!(deepcopy(vnt), 2.0, vn, e)
vnt2[vn] == 2.0 # true

I have tried to minimise it by making the chain of optics shorter, but if you make it even one element shorter, it all becomes type stable. I haven't attempted to look into why. It seems that maybe the recursive make_leaf call is OK since the initial value creation is type stable, but the recursive _setindex_optic was not as carefully written.

Reproduce the Julia 1.11 examples with templated_setindex!!, setindex!!, VarNamedTuple, and @varname to confirm the inference failures. Inspect the recursive make_leaf and _setindex_optic paths mentioned in the issue, then add or update a regression test showing the nested calls are type stable while preserving the demonstrated values.