PR #3416 - hatayama/unity-cli-loop

Summary

When the Unity Editor main thread has been stuck for 30 seconds, the CLI now tells you on stderr even when stderr is not a terminal, so agents see why a command is waiting.

Refs #3411. The Unity-side fail-fast for a command still waiting to start (MAIN_THREAD_BLOCKED) comes in a separate PR.

Before: the "Unity main thread stuck 30s; check modal/long operation..." notice was only drawn on the spinner, and the spinner is shown only when stderr is a terminal. Agents read stderr through a pipe, so a command waiting on a modal dialog printed nothing until it finished or the CLI gave up after 5 minutes.
After: without a spinner the same notice is written to stderr as a plain line, at most one line per minute so a long stall does not flood the output. With a spinner nothing changes: the notice still replaces the spinner text in place.

The progress handler now passes stall notices to a new spinner notice method that falls back to a rate-limited plain line when the spinner is disabled. A disabled spinner also records that it was stopped, so a notice arriving after the command ends writes nothing.
Shared release input stamps are refreshed for the cli/common change.

go test ./ui/... ./unityipc/... ./clicore/... in cli/common, including five new spinner tests (plain line, one line per minute, nothing after stop, in-place update with a spinner, progress handler writing the notice without a spinner).
gofmt -l, go vet ./..., and golangci-lint run ./... are clean in all four Go modules; go test ./... passes except tests that bind Unix sockets or create directories under /tmp, which the local sandbox denies (left to CI).