[Bug]: Terminal resize SIGWINCH forwarding prints missing signal in xpc message

[ChasLui]

Description

When running a long-lived foreground command with container run, terminal resize events can produce repeated XPC signal forwarding errors on stderr:

failed to send signal: ["error": invalidArgument: "missing signal in xpc message", "signal": 28]

Signal 28 is SIGWINCH. The workload continues compiling, so this appears to be a CLI/terminal resize forwarding issue rather than an application failure, but it pollutes stderr during long-running builds and makes it harder to detect real build errors.

Environment

container CLI version 1.0.0 (build: release, commit: unspeci)
macOS 26.5.1 (25F80)
Darwin 25.5.0 arm64
Host hardware: Apple Silicon
Shell: zsh

container system status reports the apiserver running:

status             running
apiserver.version  container-apiserver version 1.0.0 (build: release, commit: unspeci)

Observed output

This happened while running a Rust build in a foreground Apple container session. The build was still making progress, then stderr repeatedly printed:

   Compiling tokio v1.52.3
   Compiling futures-macro v0.3.32
   Compiling futures-task v0.3.32
   Compiling serde_json v1.0.149
   Compiling futures-util v0.3.32
   Compiling pkg-config v0.3.32
failed to send signal: ["error": invalidArgument: "missing signal in xpc message", "signal": 28]
failed to send signal: ["error": invalidArgument: "missing signal in xpc message", "signal": 28]
failed to send signal: ["error": invalidArgument: "missing signal in xpc message", "signal": 28]
failed to send signal: ["error": invalidArgument: "missing signal in xpc message", "signal": 28]

Expected behavior

Terminal resize events should either:

• be forwarded successfully as SIGWINCH, or
• be ignored without printing an internal XPC error to stderr.

The CLI should not emit repeated internal missing signal in xpc message errors during normal terminal resize handling.

Notes

A direct signal send did not reproduce the same error:

CID="$(container run --detach quay.io/libpod/alpine:latest sleep 300)"
container kill --signal WINCH "$CID"
container kill "$CID"

That suggests the issue is likely specific to the foreground CLI's terminal resize/signal forwarding path rather than generic signal delivery.

[chengboonrong]

I'm working on this. Same root cause as #1941 (client sends the signal as an Int64, server reads a string). Opened #1997, which also covers SIGWINCH resize forwarding.