fix(arp): hardware-address messages lack the protocol prefix, and a bool gets FieldValueError #2256

Describe the bug
ARP._make_addr_resolve has three problems in its hardware-address messages, raised both on the Ethernet branch and on the generic one:

• Format: the messages are capitalised and carry no protocol prefix: Invalid MAC address: … and Invalid hardware address: …. Every other ProtocolError message in pcapkit/protocols uses the <prefix>: invalid X: … form, and since fix(ethernet,pcapng): reject a non-string MAC or EUI address (#2222) #2232 so do Ethernet and PCAPNG.
• Type message: a wrong type gets the same message as a malformed string. It doesn't say "must be a str, bytes or bytearray, not …".
• The bool check: it is separate and raises FieldValueError, so except ProtocolError misses it. The owner had the same check dropped from the Ethernet and PCAP-NG makers in fix(ethernet,pcapng): reject a non-string MAC or EUI address (#2222) #2232. Here its NOTE justifies it by matching _make_proto_resolve, whose IP branches raise FieldValueError through parse_ip_address (fix(arp): a bool or int protocol address with a non-IP ptype raises TypeError, not FieldValueError #2166).

Reproduction (main 31142a816)

>>> ARP()._make_addr_resolve(True, Hardware.Ethernet)
FieldValueError: ARP: invalid hardware address: must not be a bool, not True -- pass int(True) if the numeric value is what is wanted
>>> ARP()._make_addr_resolve(5, Hardware.Ethernet)
ProtocolError: Invalid MAC address: 5
>>> ARP()._make_addr_resolve('zz', Hardware.Ethernet)
ProtocolError: Invalid MAC address: 'zz'

Expected behavior
ARP: invalid MAC address: must be a str, bytes or bytearray, not 5, and ARP: invalid MAC address: 'zz'.

Decision needed: whether the hardware path keeps its bool check. Recommendation: drop it, as #2232 did. A hardware address converts no int, so the True → 0.0.0.1 problem the guard exists for can't occur there. _make_proto_resolve keeps its check, because its IP branches can.