Glad to know you fixed it. But I think it's still not optimally fixed.
The ideal situation is that you trim the images BEFORE you use them in Spine, before packing. (that is, they should be trimmed when you export them from photoshop or whatever program you used)

The reason it broke was because meshes use UV coordinates to decide which part of a defined rectangle (the libGDX atlas-defined rectangle is called an atlas Region) goes to which vertex. When the image gets trimmed, the atlas Region dimensions change but the mesh system doesn't know it. There's no apparent "fix" since just telling the system by how much the rectangle changed isn't enough. If a mesh can potentially have vertices defined outside of that rectangle, at runtime, the mesh will render things coming from other rectangles. If the UVs are assigned to the same shape but scaled down relative the scaled down rectangle, you'll have incorrect parts of the image bound to the vertices. Obviously, neither of these fix anything.

So the real fix (right now) to always pre-trim your images before using them in Spine— or replacing the ones you currently have with pre-trimmed versions, and then realigning them, and cleaning up the mesh shape. There are Photoshop and Gimp scripts that can trim and export layers and prepare them for use in Spine.

We've been bugging Nate to put a clear warning in Spine Editor when you're using meshes and you have untrimmed images, but I guess he's holding out for a more elegant fix? This does happen a lot to people. :p

Come to think of it, I notice you're packing with XML for Starling.
Were the affected images assigned to meshes? Or were they just regular Region Attachments?
(It's not a bug if it's as I described above with meshes, but it could be a real bug otherwise, whether with Spine or with TexturePacker's packing format for Starling.)

PS
Does TexturePacker have a free version now?