[Feature Proposal] Migrate `dict` return types to `TypedDict`

[Apricot-S]

Summary

Several functions currently return plain dict objects.
Migrating these return types to TypedDict will improve type safety, clarify return structures, and enhance the overall developer experience.

Motivation

Returning untyped dictionaries makes it difficult for static analysis tools and IDEs to guarantee key existence or value types.
Introducing TypedDict provides explicit structure and improves maintainability.

Pros

• Smaller impact on existing code compared to migrating to dataclass
• Clearer and more explicit return value structures
• Improved type safety and better IDE auto‑completion
• Enhanced static analysis accuracy (e.g., mypy)

Cons

• TypedDict is not a subclass of dict, so some existing code may raise type errors
• This migration introduces breaking changes

Target Functions

• ScoresCalculator.calculate_scores()
• Aotenjou.calculate_scores()
• FuCalculator.calculate_fu()
• count_tiles_by_suits()

[Apricot-S]

We also need to consider how to handle the types of the methods that accept these dict inputs:

• FuCalculator.round_fu()
• HandResponse.__init__()

At the moment, both methods rely on the presence of the "fu" key, so the chosen type annotation directly affects whether this assumption is enforced at type-check time or only at runtime. The main options are:

1. Switch to a TypedDict

• Explicitly guarantees the presence of the "fu" key
• Improves type safety, IDE support, and static analysis
• Introduces a breaking change for existing code that passes plain dicts

2. Use collections.abc.Mapping

• Preserves compatibility with existing code
• However, the presence of the "fu" key is not enforced by the type system, so runtime errors remain possible