Fix apex SRV apply validation after variable resolution

[gudron533]

Problem

Valid Domain Connect SRV records with name: "@" fail during apply with
Invalid data for SRV host: _tcp.@.

The SRV processor resolves the name to the apex sentinel, but then validates a
synthetic _<raw protocol>.@ hostname. @ is not a DNS label; it represents
the applied domain/host apex.

This check also runs before protocol variable resolution, preventing the
protocol/service variable conventions used by the official example template.

Fix

• Resolve SRV name, protocol, and service before effective-owner validation.
• Omit the @ sentinel when constructing the owner used for validation.
• Validate the actual _service._protocol[.name] owner using the existing
  strict SRV hostname validator.
• Preserve the TCP/UDP/TLS allowlist and leading-underscore conventions.
• Safely reject an empty resolved protocol as InvalidData.

No generic hostname validator is relaxed and canonical zone-record output is
unchanged.

Tests

Adds coverage for:

• Official _sip._tls apex SRV.
• _autodiscover._tcp apex SRV.
• Both cases with host=test.
• Non-apex relative names.
• Protocol/service variables.
• Malformed name, protocol, and service.
• Complete canonical SRV output fields.

Also updates legacy tests that previously expected standards-compliant apex SRV
records to fail.

Full suite: 373 passed.

[gudron533]

I also reproduced the same failure in the current Online Editor using the already-merged official bluehost.com.email.json template. Its _autodiscover._tcp SRV with name: "" fails with the same Invalid data for SRV host: __tcp.@ error. This confirms the regression affects an existing upstream template, not only the Mailvar draft.