[os-nginx] orphaned sni_hostname_upstream_map_item / ip_acl_item entries on edit, blocking upstream deletion

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• [ x ] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• [ x ] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• [ x ] The title contains the plugin to which this issue belongs

Describe the bug
When editing an existing "SNI Upstream Mapping" entry (adding, removing, or
modifying rows), the map's child sni_hostname_upstream_map_item nodes are
never actually deleted — a brand new set of items is created on every save,
and the previous items are left behind as orphans in config.xml. If you keep
editing the same map, orphans accumulate on every save. If the whole map is
then deleted, only the last-linked set of items is cleaned up; earlier
orphans remain.

Since each orphaned item still holds an <upstream> reference to its
upstream server, SettingsController::$internalModelUseSafeDelete later
blocks deletion of that upstream server, reporting it as "in use", even
though it's no longer actually referenced from any live map.

The exact same code pattern exists for ip_acl_item (regenerate_ipacl()),
so IP ACL edits are affected identically.

To Reproduce
Steps to reproduce the behavior:

1. Services: Nginx: SNI Upstream Mapping → create a map with one hostname
   entry linked to an upstream.
2. Save. Note the item's uuid in Diagnostics: Config.xml
   (sni_hostname_upstream_map_item).
3. Edit the map (e.g. add a second hostname), save again.
4. Check Diagnostics: Config.xml — the original item from step 2 is still
   present, unreferenced by the map's data field.
5. Repeat a few times — orphans accumulate.
6. Try to delete the upstream server referenced by an orphaned item: it is
   reported as "in use" and cannot be deleted.

Expected behavior
There should be no orphans on the configuration after SNI maps o ACLs deletion

Screenshots
If applicable, add screenshots to help explain your problem.

Relevant log files
If applicable, information from log files supporting your claim.

Additional context
I found this bug while developing this feature request https://github.com/opnsense/plugins/issues/5596

Environment
OPNsense 26.7.2_2 (amd64).
VMWare ESXi 7 VM

Start at the SNI Upstream Mapping save path and trace how child items are regenerated; compare it with the related regenerate_ipacl() path for ip_acl_item entries. Reproduce the edit sequence and inspect config.xml after each save. Done means editing or deleting either map or ACL leaves no unreferenced child entries and no false upstream "in use" references.