fix(dj-name-scrub): close the gate's blind spot, scope its refusal, and stop the docs contradicting it (#2327 review)

Six findings from the review of the precondition gate. The gate's control flow was correct; the problems were around it.

Refuse on an EMPTY roster PII index. `countPollutedLegacyDjNames` returns 0 both when `shows.legacy_dj_name` is genuinely clean and when `piiNames` is empty, and nothing checked which. A broken index therefore cleared the gate while every PII-keyed decision in the job silently found nothing, and the run still logged `finished` and exited 0. Not hypothetical in this file — `loadUsers`' own docblock records that reading the wrong column made exactly this happen on 2026-08-28, before the count was load-bearing. Blocks the whole run, not just the main pass: the message and orphan passes read `piiNames` directly, so an empty index makes them vacuous rather than merely unprotected.

Scope the `shows.legacy_dj_name` refusal to the `main` pass. The precondition is about that column flowing through `resolveShowDjName` into a recomputed `dj_name`, which only the main pass does. `rewriteMessage` takes only the row's own text plus the roster index, and `loadOrphanPage` normalizes `show_id` to null on every row it returns so orphans always take `decideDjName`'s `piiOnly` branch — neither reads `legacy_dj_name`, and both only ever REMOVE a name. Blocking them held the marker-message PII fix hostage to an unrelated precondition that is unresolved pending a human policy call with no deadline. The run still exits non-zero; `ANALYZE` still runs if those passes wrote; `verifyScrub` is skipped, because the residue it would find belongs to the pass that never ran.

Rewrite the README's pre-flight section, which still documented the opposite behaviour ("does NOT abort the run", "not as a run failure to route around") at the exact heading the refusal message points an operator at. Replace the circular remedy — the only job that scrubs `shows.legacy_dj_name` is superseded and redirects back here — with the measured truth: all 839 affected shows already hold their upstream tubafrenzy DJ_HANDLE verbatim, so there is nothing to re-source and this is not turndown-gated. Clearing the gate is 3 junk `auth_user.real_name` rows plus a human policy call on 5 names, neither of which is a scrub.

Amend the `shows.legacy_dj_name` PII registry row, which still read Non-PII / "Anywhere public" on the strength of the premise this gate disproves.

Reconcile the two opposite postures sitting ~750 lines apart: this coarse proxy gates because it is cheap and runs before the pass, `recomputed_is_roster_real_name` warns because it is exact but only observable after. Measured over-count is ~0.8% (832 of 839 flagged shows really do reach the legacy arm).

Author: jakebromberg