refactor: describe a setting once, on its SettingKey

The three setting handlers were the same 53-line class three times over,
differing in one copy() field, one read, and two message keys. Adding
persistence, auditing or a permission check to settings meant writing it
three times, and a fourth setting meant a fourth copy.

A setting is its key, the messages that report it, and how it is read from
and written to PlayerChatSettings - so SettingKey now carries all of that,
and SettingHandler is the single mechanism that applies it. The registry
keeps its role as the seam where features decide which settings exist,
which is why registration is still conditional in LunaticChat.

SettingHandlerTest now asserts over every SettingKey rather than repeating
five near-identical tests per handler, so a new setting is covered the
moment it is declared. It also pins down the property that made the old
duplication dangerous: writing one setting must not disturb the others.

Co-Authored-By: Claude <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions