fix(lgsm): stream SteamCMD progress without buffering

[IOHelpMe]

Summary

• line-buffer LinuxGSM update and auto-install output with stdbuf -oL
• apply the shared template change to all nine generated LinuxGSM Scrolls
• keep SnapshotProgress as the only progress source; no estimates or synthetic values

Why

SteamCMD emits real progress frequently, but uniq buffered the pipe output. That delayed valid samples and produced the observed long pauses and large jumps. Line buffering forwards each existing progress line immediately without adding a PTY or another progress mechanism.

Verification

• go test -count=1 ./...
• ./scripts/validate_all_scrolls.sh
• git diff --check

Related: highcard-dev/druid-cli#97 and highcard-dev/monorepo#318.

[druid-infra]

Error: This repo is not allowlisted for Atlantis.

[IOHelpMe]

@MarcStdt Ready for review. SteamCMD already emitted frequent real progress, but uniq buffered the LinuxGSM pipe and released samples in large batches. stdbuf -oL forwards those same lines immediately across the shared template, with no PTY, estimates, or second progress source; Scroll tests and catalog validation pass.

[druid-infra]

Compared this against the generator/template pattern used in the repo. The change itself looks coherent; I left one non-blocking suggestion inline about broadening the regression coverage beyond a single golden example.

[druid-infra]

The template + generated YAML changes look consistent, but the new regression only spot-checks arkserver. Since this PR updates all LGSM variants, could we strengthen the test to iterate the generated LGSM scroll set (or otherwise assert the wrapper on every generated file)? That would match the repo’s generated-artifact pattern better and make future generator drift much harder to miss.