net/tayga: don't accept a netmask in the address fields

[Lux-WorldPC]

Important notices

Before you submit a pull request, we ask you kindly to acknowledge the following:

• I have read the contributing guidelines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I opened an issue first for non-trivial changes and linked it below.
• AI tools were used to create at least part of the code submitted herewith.

If AI was used, please disclose:

• Model used: Claude Opus 5, via Claude Code
• Extent of AI involvement: analysis, the patch and the test scripts. Every result below was produced
  on a real installation, against the endpoints the settings page itself posts to
  (/api/tayga/general/set and /api/tayga/service/reconfigure), and I reviewed each one before
  posting.

---

Describe the problem

The four address fields are NetworkField without NetMaskAllowed, so a CIDR suffix passes
validation. Nothing downstream accepts one: rc.d/opnsense-tayga appends its own mask, and
tayga.conf takes ipv4-addr and ipv6-addr as bare addresses.

v6destination and v4destination reach ifconfig as ${value}/128 and ${value}/32. Entering
fd00:6464::1/126 in the IPv6 NAT64 Interface Address gives ifconfig: fd00:6464::1/126: bad value,
no inet6 on the interface and nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> — the state
reported in the issue. 192.168.254.1/24 in the IPv4 field behaves the same way and leaves no inet.

v4address and v6address go into tayga.conf, where the daemon rejects its own configuration —
Expected an IPv6 address but found "fd00:6464::2/126" on line 8 — and exits 1. Started from the rc
script it prints nothing at all, so what the user gets is ifconfig: interface nat64 does not exist
three times, the same from route, and no interface.

In all four cases Save returns saved and Apply returns status: ok, so nothing in the GUI says
the address was not applied.

Measured on 26.1.11_10 / FreeBSD 14.3-RELEASE-p10, os-tayga 1.5, tayga 0.9.6, one field at a time
with the defaults restored between cases. The issue reports 26.7.1, which I do not have; the plugin
version is the same.

---

Describe the proposed solution

Set NetMaskAllowed to N on those four fields, and give them a validation message: the default one
offers "a valid network segment or IP address", which is what the change now refuses. The wording is
the one already used in sysutils/node_exporter. v6prefix and v4pool are untouched — those two
do take a network.

Each of the four inputs above is now refused against the right field with that message, while the
same addresses without a suffix save. None of the four refused forms works today — two leave the
address unset, two stop the daemon from starting — so no configuration that currently works becomes
invalid. An accepted configuration applies cleanly: inet and inet6 both present, no IFDISABLED,
the daemon running and the routes added. v6prefix at 2001:db8:64::/96 and v4pool at
10.64.0.0/16 still save and still work.

The issue only reports the IPv6 interface address. I included the other three because they fail the
same way and would otherwise stay open; happy to narrow it to v6destination if you would rather.

One limitation worth stating: this does not reach installations that already stored such a value.
performValidation() only validates fields that changed (BaseModel.php:637), so with
fd00:6464::1/126 in config.xml I re-saved the page untouched and it passed, changed another field
and it passed too; the message appears only once that field is edited. Such an installation is no
worse off either — the settings page still opens and the runtime behaviour is unchanged. The model's
treatment of the data is unchanged, so no migration and no model version bump.

PLUGIN_REVISION left alone.

---

Related issue

Closes #5594