[#8986] Cancel and Decline Reasons Move to the DB

[eanders]

Merging this PR

• use the squash-merge strategy for PRs targeting a release-X branch
• use a merge-commit or rebase strategy for PRs targeting the stable branch

Description

• Move decline/cancel reason configuration for match decisions out of ~20 hardcoded Ruby concerns and into the database (MatchDecisionStep, MatchDecisionReasonAssignment), scoped per route and per step.
• Add admin UI for managing the reason catalog (/admin/match_decision_reasons) and per-route/per-step reason assignments, embedded directly on the route edit page.
• Snapshot reason text onto match_decisions (decline_reason_text, administrative_cancel_reason_text) at decision time, so renaming a catalog reason no longer rewrites historical warehouse/reporting data.
• Fix Warehouse::BuildReport#explain to read the new snapshot columns instead of the live reason association (the actual bug this denormalization was needed for).
• Add a one-time backfill (cas_seeds:backfill_match_decision_reason_assignments, run on every deploy, marked for removal once fully rolled out) that reconstructs the old hardcoded lists into the new tables; delete the now-obsolete concerns and per-step overrides once backfilled.
• Add support for indicating whether a decision is CLIENT_REJECTED or PROVIDER_REJECTED per reason, with override at the step or per-route-assignment level (effective_referral_result), wired into CE APR reporting (Warehouse::ReferralEvent).
• Redesign the /admin/match_routes index (tabs for active/inactive routes, trimmed columns) and the route edit page (inline decline/cancel reasons table, breadcrumbs) for clarity.

Type of change

Checklist before requesting review

• I have performed a self-review of my code
• I have run the code that is being changed under ideal conditions, and it doesn't fail
• I have updated the documentation (or not applicable)
• I have added spec tests (or not applicable)
• I have provided testing instructions in this PR or the related issue (or not applicable)

[eanders]

Note, this is the one place we have the ability to decline a match by two contact types and they are presented with different lists of reasons. We accomplish this with the audience column. I was tempted to simply leave that off since very few installations are still using the default route, but I can see how this might be a useful feature and didn't add too much complexity.

[eanders]

@dtgreiner sorry for the big PR, but MOST of it is just deleting things.

[dtgreiner]

LGTM!