Services: Fall back to registry for protected configuration changes

[NotEnsoul]

Description

Problem

Some protected services reject configuration changes through the Service Control Manager even after elevation. The service properties dialog previously reported the failure without providing another path for applying the requested configuration.

Local debug builds could also fail to connect to their elevated phsvc helper when an installed release helper owned the shared port, or when API-build signature validation rejected the unsigned debug executable.

Solution

• Fall back to updating the service registry key when SCM configuration fails.
• Open protected service keys with backup/restore semantics under the elevated helper.
• Support service type, start type, error control, image path, load-order group, account name, display name, and delayed auto-start values.
• Do not use the registry fallback for password changes because service passwords are stored as LSA secrets.
• Return whether phsvc used the registry fallback so the UI can explain that Windows must be restarted.
• Allow an unelevated System Informer instance to apply the fallback through its temporary UAC-elevated phsvc helper.
• Give debug builds separate native and WOW64 phsvc port names and retain same-executable validation for unsigned local debug binaries.
• Preserve catalog hash errors before cleanup and correctly normalize Win32-facility HRESULT values discovered while testing the debug build.

Notes

Registry fallback changes are not observed by the running Service Control Manager. The dialog informs the user that Windows must be restarted before the new service configuration takes effect.

[dmex]

The PR is on hold temporarily due to pending changes to phsvc.

[NotEnsoul]

[jxy-s]

LGTM, thanks! Leaving my approval, but let's wait on @dmex to unblock before merging.