The over-constraint occurs because the inter-triangle link was created in a 3rd group, and so is dependent on the triangles's positions.

Relative to that 3rd group and the line in it, the 2 triangles, specifically the corners of them that you want to link to, are fixed in space. So the link line's length is determined by that. Notice in the 3rd group that there are 0 DOFs.

But when you rotate 1 of the triangles, it and its corner move in its workplane, which can drag the pt-pt constraint with it and "drive" the length of the link line.

----------------------------------------------------
I've included here 2 solution files.

In the first, ...Sol1-2groups.slvs, I eliminated the 3rd group. Then I created the link-line in the same group as the 2nd triangle (g003). As you can see, T1 can drive T2 but not vice versa. This is because they're still in different groups.

Apparently in SolveSpace, earlier groups have a precedence relative to later groups that creates this effect.

In the 2nd solution file, ...Sol2-1group.slvs, I eliminated the 2nd triangle group, too (g003). Then, in the same group as T1 (g002), I created a new workplane with Sketch > Workplane. This is similar to the new workplane you had for your T2, parallel to XZ, but not in a new group. I then drew T2 there. Then, I drew the link line from T2 to T1 in 3D and length-constrained.

This gets you the desired behavior--the triangles can move each other.

Note that, because Sketch > Workplane must be invoked while in 3D (even though your view is parallel to a workplane in the active group), the new workplane it creates can get moved in a setup like this. To prevent it from moving, I put a locked-where-dragged constraint on its origin, and a same-orientation constraint between its normal and Y. But as you work the linkage you'll see that the workplane will still go up and down. You'd have to constrain it more to stop that.