fix(cli): print find results on stdout, keep diagnostics on stderr - #1734

What

Follow-up to #1725, as discussed there: the find subcommands still print their
result tables on the module-level Console(stderr=True), so

cgc find name busy > matches.txt

captures the init chatter and loses the matches. This adds a stdout console for
the find family and routes the product to it, keeping console for prompts
and diagnostics — the same split #1725 landed for analyze.

find already sits alongside stats and diagram, which print their product on
stdout, so this closes the last command family that had its streams inverted.

Scope measured, not guessed

The follow-up was approved "in the same shape" for "the five find commands".
On current main the group actually has seven subcommands — name,
pattern, type, variable, content, decorator, argument — and 28
console.print sites in that block (tests/integration/cli/test_cli_commands.py:427
asserts the same seven). All seven are handled here.

24 sites move, 4 stay.

Why the four stay:

• The --type validation message is not a result and must not land in a
  redirected document — same reasoning as fix(cli): print analyze results on stdout, keep prompts on stderr #1725's third rule.
• The three Neo4j lines are environment diagnostics on a failure path, not the
  answer to the query that was asked, and they are followed by an empty-result
  notice that is the result and does move.

The wildcard/regex note (2322) and the truncation footers move because they
qualify the rows the caller is about to read — consistent with treating the
analyze footer as part of the product.

A separate find_result_console is added rather than reusing
analyze_result_console, so the already-reviewed analyze symbol keeps its
meaning and this change cannot regress it.

Tests

tests/integration/test_find_text_output_stream.py mirrors
tests/integration/test_analyze_text_output_stream.py (isolated HOME,
DEFAULT_DATABASE=kuzudb, global context) over the seven subcommands. Each
positive case asserts both directions — header and table on stdout and the
header absent from stderr — so printing to both streams cannot satisfy it.
Empty-result notices are asserted as stdout content, and the --type error is
asserted to stay off stdout.

Committed test-first: the test commit fails 8/9 against the pre-change tree
(the ninth is the stderr guard that already holds) and passes after the fix
commit.

Smoke check on a real install, with stderr discarded:

$ cgc find name busy 2>/dev/null
Resolving context...
Initializing services and database connection...
Services initialized.
Found 1 matches for 'busy':
╭──────┬──────────┬──────────────────────────╮
│ Name │ Type     │ Location                 │
├──────┼──────────┼──────────────────────────┤
│ busy │ Function │ /tmp/…/repo/app.py       │
╰──────┴──────────┴──────────────────────────╯

Local verification

• CI-equivalent pytest tests/unit/ tests/integration/ (i.e. ./tests/run_tests.sh fast) on this branch at b05d549, two back-to-back runs: 1605 passed, 0 failed, 8 skipped in 16:40 and 1605 passed, 0 failed, 8 skipped in 16:32.
• Both stream files together (test_find_text_output_stream.py + test_analyze_text_output_stream.py) → 13 passed in 131 s.
• ruff check on the changed file → 19 findings, byte-identical to the pre-change file at a864a9f; the new test file is clean. (cli/main.py is not in the lint workflow's file list, so these are not gate findings.)

One stability note so the numbers above are read correctly: fast is load-sensitive on this machine. In an earlier session the identical command on the identical tree returned 16 failures, then 1 on a repeat, with no overlap between the two sets — and most of those files are untouched by this branch. The two runs above are clean; CI is the better arbiter for this suite.

What the change actually does, measured

Same fixture (1 file, 3 function nodes, isolated HOME, DEFAULT_DATABASE=kuzudb), same command set, same interpreter — the only variable is the code version: a864a9f versus this branch. Every command is read-only, so the database is identical for both runs.

Two cross-checks that come out of this table:

1. The payload is unchanged, only its stream moved. For find name busy: before 462 B - 109 B = 353 B, after 445 B - 92 B = 353 B. The residual bytes are what stays behind on each stream (two config lines on stderr; three pre-existing progress lines on stdout), so the table itself is byte-identical on both sides — this change does not touch rendering.
2. Blast radius. The two analyze rows are identical before and after, which is the same guarantee the existing test_analyze_text_output_stream.py locks in: the new console does not reach into fix(cli): print analyze results on stdout, keep prompts on stderr #1725's symbols.

One adjacent thing, deliberately untouched

Those three progress lines ("Resolving context…", "Initializing services…",
"Services initialized.") are already on stdout today for every command, so
post-change stdout is chatter + table. A script consuming find output still
has to skip that prefix; analyze, stats and diagram have the same property
today. Fixing it means deciding where those stage messages belong, which is a
different contract question than this one, so it stays out of this PR.