[no-ticket] Have reviews catch renames of names persisted outside the codebase

[bockets]

no-ticket

A 204-file rename of Billing::BusinessEntitlement to Billing::OrganizationEntitlement renamed a Sidekiq job along with it. The queue and retry set store a job's class as a string, so every instance already in Redis at deploy time would have raised NameError on constantize and gone on retrying for weeks. The review approved the PR; the miss only surfaced from a manual second look.

The general shape is a name that lives somewhere other than the codebase — Redis, a database column, a third party's records — written by code that is already running and read back by the new code after the deploy. The diff shows the rename and nothing about the data still using the old name, so there is nothing on the page to react to unless the reviewer is looking for it.

prompts/_shared/rename-compatibility-rules.md asks for that check and lists where the old name typically survives: Sidekiq/ActiveJob classes, maintenance task names in maintenance_tasks_runs, STI and polymorphic type columns, GlobalIDs, ActiveHash ids, Flipper keys, cache and Redis keys, experiment names, and keys already sent to a third party such as Stripe subscription metadata. It also says plainly that renaming the Ruby constant while leaving the persisted name alone is correct, so a table name or metadata key that deliberately stays put does not turn into a finding.

Wired into all three prompts — codex-first-pass, claude-synthesize, and claude-synthesize-thesis-first — so both experiment arms get it.