Description
## Problem
The hydrastreamingmonitor auto-updater (6-hourly check via hydrarelease) downloads and installs whatever version hydrarelease considers latest. This overwrites manual SCP deploys, so any new code shipped outside the CI pipeline gets silently reverted within 6 hours.
This has happened repeatedly: we deploy v0.4.22 via SCP, and by next check the server is back to v0.4.29. We deploy v0.4.30, and v0.4.31 needs another SCP. The cycle repeats every release.
## Root cause
The hydrarelease mirror upload path (`project/production/version/binary-name`) does not match the GET redirect URL the updater uses (`releases/project/platform/arch/binary-version`). This means binary downloads from the mirror return 404. However, an older binary at a legacy path on the release server IS downloadable, so the updater successfully installs that stale version instead of failing cleanly.
## Impact
- Every new hydrastreamingmonitor release requires a manual SCP deploy to the server
- The auto-updater then overwrites it with the stale version from hydrarelease
- New features shipped in a release are unavailable until the next manual deploy
- Operators have no indication the running version is stale
## Fix options
1. **Fix the mirror path in hydrarelease** — align the upload path with the GET redirect URL so binary downloads succeed. This is the correct long-term fix and likely affects all services using the auto-updater.
2. **Pin the version in config** — add a `pin_version` field to the updater so the service does not self-update beyond a specified version. Workaround only.
3. **Disable auto-update for hydrastreamingmonitor** — if the service is always deployed via CI anyway, the auto-updater adds no value and only causes regressions.
## Recommended
Fix option 1 (mirror path alignment in hydrarelease). Investigate whether other services are silently affected by the same path mismatch.
## Project
hydrastreamingmonitor (symptom), hydrarelease (root cause)