ast-grep pack: string-concat-in-loop was not re-audited in the #24 measurement pass

Recording a known gap rather than leaving it implicit in a closed issue's comment thread.

The #24 pass measured every Python pack candidate against a purpose-built corpus and hand-read the
false-positive rates: `test-without-assertion` (16/20 FP), `placeholder-implementation` (14/14 on
the non-test residual), and `todo-marker` (0/20 FP, kept `off` on volume grounds). Numbers are in
`docs/pack-rule-audit.md`.

**`string-concat-in-loop` was not re-audited.** It is a Python rule shipping `severity: off`, so it
falls squarely inside #24's premise — "both Python rules default to off, so the pack contributes
nothing to a default Python run" — and it was the one that did not get measured. It stays `off` on
its pre-existing rationale: it flags a performance smell rather than a defect, which is a weaker
claim than the other pack rules make.

To close this it needs the same treatment the others got: a corpus row, a per-repository count
(never only the aggregate), and a hand-read false-positive rate reported as a fraction — plus the
check that ruff does not already cover it. Its most likely fate is confirming `off` for a reason
that has been measured rather than assumed, which is still worth more than the current state.

Bar and procedure are in ADR 0029's amendment and `docs/harden-corpus.md`.

Start with docs/pack-rule-audit.md and the procedure in docs/harden-corpus.md, then read ADR 0029's amendment and the #24 measurement pass. Add the string-concat-in-loop corpus row, per-repository counts, and hand-read false-positive fraction, and check whether ruff already covers it. Done means the measured evidence and resulting severity rationale are recorded.

Written by the indexing model from the issue text.