fix: Use relative owner names for Gateway DNS

[mattdjenkinson]

Summary

Gateway DNS was writing DNSRecordSet owner names as absolute FQDNs (help.example.com.). Manual records and the portal zone table use relative labels (help, @), so proxy-created rows looked wrong next to SOA/NS even though DNS still resolved.

We originally chose FQDNs in enhancements#615 to remove ambiguity. In practice the zone is already on spec.dnsZoneRef, and the mixed conventions are the real cost. This change writes owner names relative to the matched DNSZone (help, a.b, @ at apex) and keeps CNAME/ALIAS content as absolute FQDNs. Existing gateway-managed records converge on the next reconcile.

Testing

I tested this on staging. The record for help was showing as help.mdj-test.online before the role out and now shows as help post role out. I also created a new AI Edge and added a custom hostname which worked correctly.

Test plan

• Unit: TestBuildDesiredDNSRecordSetSpec / TestEnsureDNSRecordSets (relative name, apex @, multi-label, casing, FQDN convergence)
• Chainsaw: task test-infra:test-e2e -- ./test/e2e/gateway (asserts owner name test and trailing-dot CNAME content)
• After deploy, create/update an AI Edge hostname and confirm the portal Name column shows the subdomain (or @), not the FQDN

Closes #317

[aflor024]

Post-merge heads up — this interacts badly with how dns-operator handles owner names.

Its queue is keyed on the raw spec.records[].name, and the update handler enqueues both ObjectOld and ObjectNew. So the FQDN→relative rewrite gives you two requests for one RRset: api writes it, api.example.com. finds no owner and deletes it. Both spellings qualify to the same PowerDNS name, which is exactly why the migration looks like a no-op. The delete fires in either order; whether the record survives just depends on which request lands last. When it loses, the RRset is gone but the DNSRecordSet still says Programmed=True, and there's no periodic requeue to fix it.

Not your bug — it's been latent in dns-operator all along, since stable owner names meant the two enqueues deduped. This just makes every gateway-managed record hit it once. Filed as datum-cloud/dns-operator#74 and fixed in datum-cloud/dns-operator#75, merged 17:12 UTC. Both orderings are covered by tests there, and both fail against unpatched main.

Timing is worth flagging though: v0.24.8 put the rewrite into prod at 10:08 UTC, and the dns-operator fix isn't there yet. The agent that runs dnsrecordset-powerdns had been frozen on v0.6.4 since 09:20 UTC — its Flux Kustomization was failing to apply on an env var collision and nothing surfaced it (datum-cloud/infra#3716, fixed in datum-cloud/infra#3718). Prod's agent is on v0.6.7 now, but #75 landed after v0.6.7 was cut, so it still needs a release. Until then the window where a rewrite can drop a record is open in prod. If you know of a gateway hostname that should be resolving and isn't, that's the first place I'd look.

One small thing on this side: the out-of-zone fallback in relativeOwnerName drops the trailing dot, so other.example.org becomes other.example.org.example.com. once dns-operator qualifies it. The old FQDN form got rejected as out-of-zone; this one gets accepted silently. Should be unreachable since you match a zone first, but return h + "." would keep it failing loudly.

Edited: originally said prod was on dns-operator v0.6.6 and needed a v0.6.7 cut. v0.6.7 already existed; the real blocker was the wedged agent Kustomization in infra#3716.