Send console errors to stderr instead of stdout

[DMZ22]

• fixes Command line tools should send errors to stderr, not stdout #1749

---

print_error and print_exception rendered onto whatever console the command passed in, and every command builds a plain stdout Console(). So the reporter's case does this:

$ frictionless describe doesnotexist.csv --json > out.txt 2> err.txt
before:  stdout 324 bytes (the red error panel), stderr 0 bytes
after:   stdout 0 bytes,                          stderr 324 bytes

Both helpers now print to a module-level Console(stderr=True), including the debug=True path, which called console.print_exception() and would otherwise have kept leaking tracebacks to stdout.

@pierrecamilleri — your comment named helpers.py as the fix locus, which is right, but there is one call site in there that must not move:

extract.py:233 calls print_error(console, note="No rows found", title="Empty") from inside the table-rendering loop, after console.rule("[bold]Tables") and followed by continue. That is report content on a successful run (exit 0) using print_error purely for the red panel styling. Sending it to stderr would tear it out of the sequence of tables it sits between. So it moves to a new print_panel helper that renders on the passed console. Verified: frictionless extract empty.csv still prints "No rows found" to stdout, exit 0, with stderr empty.

I kept the console parameter on both helpers rather than dropping it and touching all 31 call sites across 12 command files. It is unused in print_error/print_exception now, which is a little untidy — happy to remove it and update the call sites if you'd prefer that diff.

Tests. Five console tests asserted error text on result.stdout; they now assert on result.stderr, which is precisely the behaviour under change:

• test_describe.py::test_console_describe_error_not_found
• test_transform.py::test_console_transform_error_not_found_source_issue_814
• test_validate.py::test_console_validate_single_invalid_resource_221
• test_extract.py::test_console_extract_single_invalid_resource
• test_extract.py::test_console_extract_single_valid_resource_invalid_package

Two new tests pin the separation directly: an error run must leave stdout completely empty while stderr carries the message, and a successful --json run must still produce parseable JSON on stdout with stderr empty. Reverting the source while keeping the tests fails the first of those; the second passes either way, deliberately, so it catches over-correction.

pytest frictionless/console goes from 4 failed / 85 passed to 4 failed / 92 passed — the four are pre-existing dialect_sheet_option failures unrelated to this change and present on unmodified main. ruff check reports the same counts on both files I touched before and after (182 and 33), so this adds no new lint findings, though note those counts are from a newer ruff than the pinned one.

I did not add a CHANGELOG entry since there is no unreleased section, but this is a user-visible behaviour change for anyone parsing stdout, so say the word if you want one.

[pierrecamilleri]

Thanks, I additionnaly removed the wordy LLM comments, and adapted the tests for python 3.9 support.