feat(rules): bug-println flags eprintln!; bug-expect flags expect("<invariant>") like a bare unwrap() #682

Problem

Two built-in Rust rules fire on idioms that are normally intentional, which makes cora scan output noisy and trains people to ignore the rule entirely.

1. bug-println also matches eprintln! / eprint!

Stderr diagnostics are the usual way a library or CLI reports non-fatal problems; they are not the stdout noise the rule is about. Repro (cora 0.19.0):

fn a(){ println!("x"); }     // flagged (expected)
fn b(){ eprintln!("ok"); }   // flagged (unexpected)
fn c(){ print!("y"); }       // flagged (expected)

In a real workspace all 11 hits in the library crate were eprintln! (hook-failure diagnostics, etc.). The 0.19.0 changelog already exempts main.rs, src/bin/, examples/, benches/; the other modules of a binary crate (where stdout is the product's interface) still produce 64 hits.

2. bug-expect does not distinguish a message that states an invariant

37 hits in the same workspace; every one looked like child.stdout.take().expect("stdout piped above"), .lock().expect("busy lock"), .build().expect("tokio runtime"). These are the documented-panic pattern the Rust API guidelines recommend over bare unwrap().

Proposal

• bug-println: do not match eprintln!/eprint!/dbg!-style stderr macros; treat every module of a package that has a [[bin]]/src/main.rs target as program code (or add rules_engine.binary_crates: true), keep flagging println!/print! in library targets.
• bug-expect: skip (or downgrade to info) when the argument is a non-empty string literal; keep flagging expect("") and unwrap() (that is bug-unwrap's job).

Done when

The repro reports lines 1 and 3 only; expect("stdout piped above") is not reported while expect("") and .unwrap() still are; tests for a binary crate vs a library crate.

Related: #663.