Write diagnostic warnings to stderr instead of stdout

[jedisct1]

Change summary

Expiration warnings, profile-not-found warnings, and config permission warnings were written to stdout, which broke JSON parsing when --json was used. Now warnings go to stderr instead.

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes to Core Features:

• Have you written new tests for your core changes, as applicable?
• Have you successfully run tests with your changes locally?

User Impact

Users piping CLI output through jq or other JSON parsers will no longer encounter parse errors caused by diagnostic warnings mixed into stdout.

Are there any considerations that need to be addressed for release?

No breaking changes.

[philippschulte]

Do the tests really verify the regression, because most of them set ErrOutput to the same buffer as Output. I don't think they catch accidental writes to stdout.

Maybe it would be good to add a test with separate stdout/stderr buffers and assert that warnings land only in stderr while stdout remains valid JSON?

[jedisct1]

Maybe it would be good to add a test with separate stdout/stderr buffers and assert that warnings land only in stderr while stdout remains valid JSON?

Added, thanks!

[philippschulte]

Looks good to me — routing these diagnostics to stderr is the right fix, and the added tests cover the main stdout-vs-stderr behavior well.

One small thing to double-check before merging: since --json no longer sets Quiet=true and instead uses Flags.JSON, can you confirm there are no remaining command-specific !Flags.Quiet stdout messages on any JSON-capable commands?

From a quick repo search, the global paths in pkg/app/run.go look covered by this PR, so this is mostly just a final sanity check that no command-level informational output can still leak into stdout and interfere with JSON parsing.