Add contrib-search Claude Code skill; delegate rector-live-test module discovery to it
The rector development skills repeatedly need to search real contrib code for a deprecated pattern (a method, function, constant, or property a rector targets) to answer two recurring questions:
1. Is this pattern actually present in real contrib code, and how widespread is it? (used when judging whether a rector false-positive is a realistic risk, and when picking a real module to extract a PHPStan message from)
2. Which D11-compatible contrib modules exercise this rector, so it can be live-tested?
Today this logic lives inline in the `rector-live-test` skill (steps 1-3) and is copy-referenced ad hoc elsewhere. It should be a first-class, reusable skill.
## Proposal
Add a `contrib-search` skill (`.claude/skills/contrib-search/`) built around the `api.tresbien.tech` code index, with two exit points:
- **Quick mode (default)** - run one search query, report hit count + a few decoded example call sites. Answers question 1 without installing or ranking anything.
- **Full mode (`--full`)** - additionally filter hits to D11-compatible modules ranked by install count, producing a module list ready to live-test. Answers question 2.
Scope is contrib-only (every query includes `-r:drupal` to exclude core); the skill does not search core. No Drupal GitLab blob-search fallback.
Then thin `rector-live-test` so its module-discovery steps delegate to `contrib-search --full`, removing the duplicated search mechanics.
## Rationale
- One canonical home for the tresbien query mechanics (the `-r:drupal` requirement, regex escaping / HTTP 418 on unescaped `(`, the `Result.Files[]` shape, the `drupal-core` / `drupal-usage` repo-config filters).
- Quick mode is the lightweight lookup reached for constantly during review and QA; forcing it through the full live-test pipeline is overkill.
- Removes duplication between `rector-live-test` and other skills that need the same search.
issue