ast-grep: decide whether "test context" is one poly-level concept

Carried forward from #22 (and touched in #23). Filed so the decision is not made by accident.

poly answers "is this test code?" two unrelated ways today:

- **Syntactically**, as an ast-grep predicate — now the global util `rust-in-test-context` in
`crates/poly-core/src/engines/astgrep/builtin/utils.yml`.
- **By path**, as a rule's own `ignores:` globs (`**/tests/**`, `**/*_generated.rs`, …), merged
into `PerFileIgnores` by `engines/astgrep/exclusions.rs`.

They overlap, disagree at the edges, and neither knows about the other. A rule wanting "not in test
code" has to pick one, or write both and hope they agree.

The question is whether this should become a single poly-level concept — one definition of test
context that the ast-grep tier, the quality tier and `[per-file-ignores]` all consult — or stay two
deliberately separate mechanisms answering deliberately different questions ("which node" vs "which
file").

**This matters before a second language's test detection is written**, not after. Rust is the only
language with the syntactic predicate today. If Python or JS/TS grows one, whichever shape it copies
becomes the de facto answer, and reversing it means rewriting both rule sets.

No urgency, but it should be an explicit decision with an ADR rather than a precedent someone
inherits.

Start by reading the carried-forward discussions in #22 and #23, then inspect crates/poly-core/src/engines/astgrep/builtin/utils.yml and engines/astgrep/exclusions.rs. Compare the syntactic predicate with rule-level ignores and determine whether they should remain separate or share one poly-level definition. Done means the decision is explicit in an ADR before another language adds test detection.

Written by the indexing model from the issue text.