No, it has nothing to do with looping.
But Spine doesn't crossfade animations in different tracks. It only crossfades animations on the same track. And it can only crossfade between a currently playing animation and another animation you want to play next. Animations won't fade in while the track are empty. If you always want crossfading to happen, you should always have an animation playing.
On the other hand, Animations playing on different tracks only override each other. There's no crossfading going on there at all.
There are a lot of assumptions that Spine doesn't make because it's supposed to be flexible and programmatic-animation friendly. The main assumption it has it probably "the user could be trying to do anything, so don't do anything unless it's specified."
One of the most basic things you have to realize is that, when it plays an animation, it just applies the keys defined by the animation (changing the transform properties of bones like rotation, scale, position, slot images and nothing more). Once an animation is done playing, it won't do anything you don't tell it to. If you don't tell it to go back to its setup pose, it won't. If it doesn't have enough information, it won't try to guess what you want.
It's a very programming-y paradigm behind it. What you gain from that is flexibility required by complex animation systems, but you may lose a lot of convenience like the ones you're looking for. (Or in this case, as in many cases, it does sound like something that could be added in. But that's not really my call. There's always the issue of keeping the base implementation simple enough to maintain while providing easy access to the most common cases. Just my interpretation.)
The way I see it, you have at least two options to solve your problem.
(a)
We're only talking about the behavior of the built-in Spine.AnimationState.
Spine is source-available and modifiable so if you need something specific, read the docs and study how AnimationState works and you can make it work the way you want. You can fade-out the arm-shooting animation after it plays. That's possible to do if you code it yourself and make it do whatever you need it to do.
(b)
You can stick with the built-in AnimationState that SkeletonAnimation has.
You may have to make a new animation that the arm shoot animation can mix with on track 1.
You can copy all the arm animation keys from the running animation into a new animation, and also the arm animation keys from any other character animations you want your shooting animation to blend with.
Basically, you'll need a whole set of animations for track 1 so they can crossfade with each other.
But like I said, Spine's pretty flexible and there are likely other ways to get what you want. IK. Programmatic posing. But there's two for you.