job unblock --data is ignored when stdin is a non-TTY with no data

[nobradov1c]

Description

bk job unblock --data ... ignores the explicit --data value when stdin is a non-TTY, even when stdin contains no data. The resulting unblock request is sent without fields ({}).

This matters for CI runners and other automation where stdin is commonly connected to an empty pipe or /dev/null rather than a TTY.

Reproduction

Given a blocked job with fields:

bk job unblock "$JOB_ID" \
  --data '{"field-name":"value"}' \
  --yes --no-input --debug </dev/null

The debug output shows that the request body is {}, and the API reports missing/invalid fields. Running the same command in an interactive TTY uses --data correctly.

Expected behavior

An explicitly supplied --data value should take precedence over stdin and be sent as the unblock fields, regardless of whether stdin is a TTY.

Cause

UnblockCmd.unblockFields checks HasDataAvailable(os.Stdin) before checking c.Data. For an *os.File, HasDataAvailable returns true whenever the descriptor is not a terminal; it does not establish that bytes are actually available. With empty non-TTY stdin, the command reads an empty string, returns no fields, and never examines --data.

The relevant code appears unchanged in v3.54.0, v3.54.1, and current main.

Suggested fix

Prefer explicit --data when it is non-empty, and only inspect/read stdin when --data was not supplied. It may also be useful to add a test with stdin connected to an empty non-TTY reader.

Workarounds

Piping the JSON through stdin works:

printf '%s\n' '{"field-name":"value"}' |
  bk job unblock "$JOB_ID" --yes --no-input

Calling the REST endpoint through bk api also works.