Validate domain hostname rules per label

[gaoflow]

valid_domain? checks the hostname rules positionally against the whole domain string instead of per label. It rejects a leading hyphen only via start_with?('-') (first label only) and a trailing hyphen only via include?('-.') (a hyphen followed by a dot, i.e. non-final labels only), and it has no length check at all. So the mirror positions leak through:

ValidEmail2::Address.new("user@foo.-bar.com").valid?  # => true  (leading hyphen, later label)
ValidEmail2::Address.new("user@example.com-").valid?  # => true  (trailing hyphen, final label)
ValidEmail2::Address.new("user@#{'a' * 64}.com").valid?  # => true  (label > 63 octets)
ValidEmail2::Address.new("user@#{(['a'] * 127).join('.')}a").valid?  # => true  (domain > 253 octets)

The spec already asserts that a domain may not begin or end with a dash ("is invalid if the domain begins with a dash" / "...ends with a dash"). These are the same rule applied to every label rather than only the first and last position of the domain string, plus the RFC 1035 length limits (63 per label, 253 total). Python's email_validator rejects all four shapes.

The fix splits the domain on . and validates each label (1–63 octets, no leading or trailing hyphen) plus the overall 253-octet limit. Internal hyphens, double hyphens (a--b) and punycode labels (xn--bcher-kva) stay valid — only the boundary positions of each label are checked, so no legitimate hostname is affected.

This is scoped to label structure and length; it does not touch PROHIBITED_DOMAIN_CHARACTERS_REGEX (the separate character-set surface). It uses the existing string/regex approach rather than a full IDNA library — labels are counted in characters, which matches how the rest of valid_domain? already works.

Tests: added a parametrized table of the malformed shapes (invalid) alongside the internal-hyphen / double-hyphen / punycode / 63-octet / 253-octet cases that must stay valid. Full suite green (bundle exec rake).