fix(config): an invalid custom-rule regex is silently dropped, and cora config validate reports "Configuration valid" #684

Problem

A custom rule whose pattern is not a valid regex is neither rejected at load time nor reported at run time: the rule is silently skipped, the scan succeeds with 0 findings, and cora config validate prints Configuration valid. with exit code 0. A user who mistypes a pattern believes the rule is active and passing.

Reproduction (cora 0.19.0)

# bad.yaml
rules_engine:
  custom:
    - id: bad
      pattern: "("            # invalid regex
      severity: major
      message: m
      languages: ["rs"]
      exclude: []

$ cora config validate --config bad.yaml
... Configuration valid.            # exit 0
$ printf 'fn a() {}\n' > src/a.rs
$ cora scan --no-llm --config bad.yaml --verbose
Scanned 1 files -- Found 0 issues.   # no mention of the rule, even with --verbose

The same silence applies to a rule whose languages can never match (see #678: ["rust"] instead of ["rs"]) and to a pattern that is simply wrong (we lost time to a mis-escaped \( that compiled but matched nothing).

Proposal

1. config validate (and config load) should compile every custom pattern and fail with the rule id and the regex error.
2. config validate should also lint: duplicate ids, an id that collides with a built-in rule id, languages entries that are not known extensions, empty message.
3. Add a dry-run, e.g. cora rules test --config .cora.yaml [--path .] (or config validate --dry-run), listing per custom rule the number of files and lines it matched, so "0 matches" is visible. A rule with zero matches across the project deserves a warning.

Done when

cora config validate --config bad.yaml exits non-zero naming rule bad; a rule matching nothing is reported by the dry run; tests cover both.