Port two missed job-dispatch fixes to the metaproxies (#70215)

[ggiesen]

What does this PR do?

Ports two fixes that landed in salt/minion.py but never reached the metaproxies.

What issues does this PR fix?

Fixes #70215

Root cause

deltaproxy still double-forked every job. thread_return and thread_multi_return kept the daemonize_if block that 9f1fe42 ("Call os.fork less to avoid race conditions", 2019) removed from salt/minion.py and salt/metaproxy/proxy.py -- two years before deltaproxy.py was forked from proxy.py, so it was carried in with the fork. With the default multiprocessing: True the job is reparented to init, so the proxy's SubprocessList entry dies immediately and neither process_count_max nor the shutdown path can see or control the process actually doing the work.

Both metaproxies appended to the process title on every job. The guard added to salt/minion.py in 26fed3b for #68553 never reached salt/metaproxy/deltaproxy.py or salt/metaproxy/proxy.py. With multiprocessing: False the job runs in a thread of the live daemon, so each job rewrites the running process's title until the argv buffer fills and saturates mid-word. multiprocessing: False is the normal configuration for a proxy driving a real device, since a live NETCONF/SSH session cannot be forked.

Note this PR fixes proxy.py as well as deltaproxy.py for the second item -- the single-proxy metaproxy was missed by #68553 in exactly the same way, so fixing only deltaproxy would leave half the port undone.

Previous Behavior

deltaproxy job processes were orphaned to init, and with multiprocessing: False both metaproxies filled the daemon's process title with repeated _thread_return entries, leaving ps and top output unreadable.

New Behavior

Job processes stay children of the salt-proxy, matching salt/minion.py and salt/metaproxy/proxy.py. The process title is left alone when the job is not getting its own process, and is still set when it is.

Merge requirements satisfied?

• Docs
• Changelog
• Tests written/updated

Tests written?

Yes. Three unit tests in tests/pytests/unit/metaproxy/test_deltaproxy.py driving deltaproxy.thread_return: it must not call daemonize_if; it must not touch the process title when multiprocessing is disabled; and the inverse, that it still sets the title when the job really does get its own process, so the guard cannot silently drop the title everywhere. The first two fail against unmodified 3008.x.

Verified against a live deltaproxy on 3008.2 (one control proxy, three dummy sub-proxies):

scenario	before	after
multiprocessing: True, job process parentage	ppid=1, orphaned to init	child of the control proxy
multiprocessing: False, process title over 20 jobs	190 to 384 chars, 7 repeats of _thread_return, then saturated	190 chars, no repeats, flat

Commits signed with GPG?

No