Since the ARP packet size is fixed and smaller than a minimum Ethernet payload, padding needs to be used at all times. Wireshark most often doesn't see the FCS that's closing a received frame[1], so it needs to apply some guesswork as to which bytes might be padding. It calls these excess bytes trailer. Padding might show up on sent frames, although these padding bytes aren't usually visible (since they're only added by the NIC/driver).
Basically, it's the same thing - provided Wireshark correctly interprets the frame contents.
[addition for 2nd screenshot]: I'm counting 18 padding bytes which is the exact difference between the ARP packet size (28 bytes) and the minimum Ethernet payload size (46 bytes) - that's padding as required by Ethernet and recognized as such by Wireshark.
The rest is excess data (garbage?) that is trailing the minimum frame, so it's labeled as Trailer. It looks like it starts with the (possibly correct) FCS, followed by some more bytes - potentially metadata misinterpreted by Wireshark, which would also explain the FCS status bad.
You might need to recheck the import options for the dump for Wireshark to make more sense of it.
[1] The real frame end is indicated by the physical layer by just stopping the carrier signal or sending a special symbol (depending on the variant). This isn't visible to the capturing library at any time. The NIC driver just provides a buffer containing bytes, usually also stripped of the FCS.
