Frozen dataclasses: sealable

[tony]

Task:
Provide a structured summary and action plan for implementing a Python 3.9-compatible function, frozen_dataclass_sealable(). This function should emulate frozen dataclasses but uniquely allow inheritance between frozen and non-frozen dataclasses. Ensure the proposed implementation explicitly addresses the provided test requirements.

Constraints and Clarifications:

• Clearly indicate complexity or feasibility concerns (rated on a scale from 1 to 10) if certain test requirements—such as implementing __slots__—are too complex or impractical to satisfy.
• Simplicity and practicality are prioritized. It is acceptable to impose limitations, such as not achieving complete immutability (true freezing), particularly regarding mutable attributes like lists.

Non-negotiable Requirements:

#	Requirement	Clarification
1	Field inheritance between frozen and non-frozen dataclasses must be supported	Derived classes should inherit and extend fields without restriction from frozen parents
2	Full compatibility with type annotations and static type analysis (auto-completion, IDE support)	Type hints and static checks (e.g., mypy) must remain fully accurate and reliable
3	Python 3.9+ compatibility required	No backward compatibility below Python 3.9 necessary

Concept Explanation: "Sealable Fields":
A "sealable field" is temporarily mutable during initialization, specifically within the context of __post_init__(). After initialization (seal()), these fields become effectively immutable. Static type checkers and IDE tools should treat these fields as read-only outside the initialization phase.
The rationale is to allow complex object graphs and circular or bi-directional dependencies to be resolved naturally during __post_init__() initialization.