fix(dns): a forward record is named by its assignment

[v0l]

PATCH /api/admin/v1/vm_ip_assignments/{id} accepted dns_forward, documented it as the forward FQDN, wrote it to the database and never sent it to DNS. BasicRecord::forward derived the record name from the VM id and never read the stored value, so the row and the nameserver disagreed. Reverse worked, because reverse_to_fwd does read its stored value.

forward now uses dns_forward when set, falling back to the derived vm-{id} label when it is not, so clearing the field restores the old name.

The FQDN question

The issue flagged this as the thing not to guess at, and it is the only real decision here. The derived name is a bare label that Cloudflare expands against the zone. Accepting a label as a stored name would turn host into host.lnvps.cloud.lnvps.cloud on live records for every VM in a shared zone, not only the one being renamed.

So a stored name must be a full FQDN, as reverse names already must. That is also what a create writes back, since providers return the record's resolved name. The fallback stays a label because there is no stored name for the zone to disagree with.

Checked against production rather than assumed

Of 1787 assignments: 1348 have no forward name, 439 hold an FQDN, none hold a bare label, so nothing starts failing validation.

Of the 439, the only rows whose name is not already vm-{vm_id}.<zone> are the six belonging to the three route servers, which are the rows the bug was found on. For every other row the record produced is unchanged.

Test

a_forward_record_is_named_by_the_assignment covers the derived name, the stored name (keeping its provider reference, so the record is renamed rather than duplicated), the vm-42.lnvps.cloud form every un-renamed row already holds, and the rejected bare label. Verified to fail with left: "vm-42", right: "ie-01.vpn.example.com" when the fix is reverted.

2052 pass, clippy clean.

Fixes #410