refactor(server): dedupe award handlers and mutate-then-report response tail

[QMalcolm]

Closes #130.

What

Two commits, one per dedupe target from the issue:

1. Shared response tail — the resolved_state → pending_choices → serialize_character → Map.put(:pending_choices, ...) sequence was repeated at five handler tails (build_finish, both award clauses, both resolve_choice clauses), four of them calling parse_display_mode(msg) twice. character_with_choices_response/4 now owns the sequence and parses the display mode exactly once per request. (build_finish had already drifted into a differently-shaped copy of the same logic — now it's the same call as everyone else.)

2. One award handler — the two characters.award clauses merged into one that branches on Map.fetch(msg, "value"). The branch returns {value, response_extras} so the value source and its :awarded_xp enrichment stay paired: the key appears only when the server computed the amount, preserving response shapes exactly.

Notes

• Map.fetch rather than Map.get preserves an edge case of the old pattern-match dispatch: an explicit JSON null value still takes the explicit-value path (failing in apply_award!) instead of being reinterpreted as a computed award.
• Net −35 lines across the two commits.

No behavior change; all 389 tests pass unchanged, credo and dialyzer clean.

Summary by Bito

• Refactored character response generation into a new helper function `character_with_choices_response` to reduce code duplication across multiple handlers.
• Removed redundant `handle` function for `characters.award` that accepted a specific value, consolidating logic into the main award handler.
• Updated `characters.award` handler to dynamically compute award values when not provided, returning the computed amount in the response.
• Standardized response structure for character mutation commands (award, decision, etc.) using the new helper.