update_manager: add path to update status response

[bassco]

Summary

• Add 'path': str(self.path) to AppDeploy.get_update_status() — propagates to all deployer types (git_repo, web, zip, python) via super().get_update_status()
• PackageDeploy (system) is unaffected — it inherits from BaseDeploy, not AppDeploy

Problem

The /machine/update/status API returns detailed info for each configured updater (channel, version, commit info, remote URL) but omits the local filesystem path, even though it's a required config field. Clients that need to interact with managed repos on disk (e.g. running scripts or firmware tools) must parse moonraker.conf directly — fragile and duplicates config-parsing logic Moonraker already handles.

Real-world use case: KlipperFleet PR #19 adds Beacon probe flashing, which needs to locate the beacon_klipper repo to run update_firmware.py.

Live verification on Voron 2.4

Before (upstream master)

No path field in any updater entry:

system: NO path field (configured_type=system)
moonraker: NO path field (configured_type=git_repo)
klipper: NO path field (configured_type=git_repo)
beacon: NO path field (configured_type=git_repo)
fluidd: NO path field (configured_type=web)
mainsail: NO path field (configured_type=web)
...

After (this PR)

All AppDeploy-based updaters now include path; system is correctly excluded:

system: NO path field (configured_type=system)
moonraker: path=/home/pi/moonraker
klipper: path=/home/pi/klipper
fluidd: path=/home/pi/fluidd
z_calibration: path=/home/pi/z_calibration
katapult: path=/home/pi/katapult
beacon: path=/home/pi/beacon_klipper
klipperfleet: path=/home/pi/KlipperFleet
mainsail: path=/home/pi/mainsail
...

Files changed

File	Change
moonraker/components/update_manager/app_deploy.py	Add 'path': str(self.path) to get_update_status() dict

[Arksine]

FWIW this information is available via GET /server/config without parsing moonraker.conf. The backend will simply need to expand the home directory if the path includes a ~.

The update manager doesn't include the full configuration in its status response, it returns generally pertinent information about the application and its source. Some of these may be items are part of the configuration, however it is possible that they could deviate from their configured values which is why they are reported.

[bassco]

Thanks for the pointer! /server/config works perfectly — tested on a live Voron 2.4:

$ curl -s http://localhost:7125/server/config | python3 -c "
import json, sys
data = json.load(sys.stdin)
config = data['result']['config']
for k, v in config.items():
    if k.startswith('update_manager ') and 'beacon' in k.lower():
        print(f'{k}: path={v.get(\"path\")}')"

update_manager beacon: path=~/beacon_klipper

After os.path.expanduser() on the printer → /home/pi/beacon_klipper ✓

Updated KlipperFleet to use /server/config instead of parsing moonraker.conf. Closing this PR — no upstream change needed.

[bassco]

FWIW this information is available via GET /server/config without parsing moonraker.conf. The backend will simply need to expand the home directory if the path includes a ~.FWIW this information is available via GET /server/config without parsing moonraker.conf. The backend will simply need to expand the home directory if the path includes a ~.

Thanks for the feedback and this API location. I'll implement this using the existing endpoint.
(I need to press send before the work is completed 😊 )