output and export helpers report success after write failures

[GautamSharma99]

Summary

The shared output helpers do not propagate serialization, write, flush, or close failures. Some paths print a success message after an ignored failure.

Source references (current main):

• OutputJSON prints marshal errors and returns no error
• OutputJSONL ignores marshal, write, separator, and close errors
• PrintOutput ignores both JSON marshaling and os.WriteFile failures
• Trace JSONL export repeats the unchecked write/close pattern

For example, PrintOutput can fail to write the requested output path and still return normally. OutputJSONL prints that output was written even if a later write or close failed.

Why this matters

Failures caused by disk exhaustion, permissions, a broken pipe, filesystem errors, or unsupported values can result in missing or truncated exports with exit status 0. A caller may delete its source data or advance a checkpoint based on a success message even though the output is unusable.

Close errors matter for files because buffered or delayed filesystem failures can first surface during close.

Expected behavior

Output functions should return errors, and command RunE handlers should propagate them so the CLI exits non-zero. Success output should only be emitted after all writes and the final close complete successfully.

Suggested tests

• Inject a writer that fails after a partial write.
• Attempt output to an invalid/unwritable path.
• Assert that close failures and JSON marshal failures reach the command caller.
• Assert that no success message is printed following a failed export.