`pfsense_dns_resolver` overwrites pfBlockerNG-owned `<unbound>` keys (`custom_options`, `python`, `python_order`, `python_script`)

[wpfleger96]

Is your feature request related to a problem? Please describe.

pfBlockerNG-devel (DNSBL in Python mode) owns four keys under <unbound>: it regenerates custom_options (base64) on every DNSBL reload and sets python=on, python_order, python_script. pfsense_dns_resolver always writes custom_options (defaults to "", so an omitted param base64-encodes an empty string and wipes pfBlockerNG's block):

# plugins/modules/pfsense_dns_resolver.py, _params_to_obj()
obj["custom_options"] = base64.b64encode(bytes(params['custom_options'], 'utf-8')).decode()

and the python* keys are commented out of the argument spec (lines 346–348), so the module has no way to preserve them. Result: running the module on a box with pfBlockerNG DNSBL enabled breaks DNSBL until the next pfBlockerNG reload, and every subsequent run fights the package.

This is the same class of problem as #153 (hosts/domainoverrides are replaced rather than merged) and the preserve option proposed in #179 — but that PR's preserve covers hosts, domainoverrides and custom_options, not the python* keys.

Describe the solution you'd like

Either:

• Only write keys that were explicitly passed (treat omitted params as "leave as-is"), so custom_options, python, python_order, python_script survive when not declared; or
• Extend feat(pfsense_dns_resolver.py): Option to preserve unbound hosts #179's preserve to also leave the python* keys untouched, and document that custom_options must not be declared alongside pfBlockerNG.

Describe alternatives you've considered

We manage every non-pfBlockerNG <unbound> key via pfsense_phpshell with a small PHP script that only touches named paths — works, but bypasses the module entirely.