fix(settings): reject hero settings members for slots the hero lacks

[e54-bot]

Summary

Closes #429.

The audit's remaining live defect for this issue was a validation gap: a
hero-scoped settings member like Doctrine { enableAbility3: Off } passed
check and then failed emission with a missing setting mapping error —
or worse, risked spelling a malformed %1$s row for a hero that has no
corresponding ability slot at all.

check_emission's walk_heroes now rejects such a member when it is not
raw, has no reviewed per-hero display label, and the gameplay catalog
proves the hero lacks the ability slot. Unknown heroes keep the previous
behavior, and slots the hero does own (e.g. Doctrine ability1Cooldown%,
whose label is composed from gameplay names) still emit and round-trip.

Investigated audit findings already covered on main (PR #433):

• wreckingBall canonical mapping — wrecking_ball_hero_settings_emit
  and wrecking_ball_zh_label_binds_secondary_fire cover the en and zh
  label bindings; no stale hammond mapping remains.
• Mode-inherited settings — mode_inherited_setting_resolves_typed and
  game_mode_start_all_slots_filled_resolves cover typed resolution;
  self-referential suggestions were not reproducible.
• ability1Cooldown% under rowless heroes — resolved through the
  gameplay-name template; the new check keys on missing ability slots,
  not on absent generated rows.

Test plan

• cargo test -p workshop-rs --lib audit_regressions — 26 pass,
  including the new hero_member_without_slot_is_rejected_by_check
• cargo test --workspace --all-targets — all suites pass
• cargo fmt --all --check, cargo clippy --workspace --all-targets -- -D warnings, workshop-catalog-gen -- check, git diff --check