Restrict state restore to declared dataclass fields

[richard-to]

Summary

• A security advisory reported that update_dataclass_from_json (via /__ui__ UserEvent state blobs) blocks dunder keys and unhashable class-level defaults, but ordinary non-dunder keys can still reach hashable, mutable class-level attributes through normal hasattr/getattr/setattr fallback — letting a crafted state payload mutate an object shared across all sessions (e.g. a dict subclass with a custom __hash__ used as a class attribute on a nested state object).
• I reproduced the chain against current main and confirmed it's valid: the mutation lands during update_state() in mesop/runtime/context.py, which runs before the handler-id lookup, so the developer error returned afterward doesn't roll back the damage.
• Fix: in _recursive_update_dataclass_from_json_obj, a non-dunder key resolved via hasattr is now also required to be a declared __dataclass_fields__ entry on the target — unless the target is a plain dict (dict-typed state fields, e.g. dict[str, bool], still restore arbitrary keys as before).

Test plan

• Added test_class_level_attribute_pollution_blocked reproducing the advisory's RoleService/MutableRoleMap PoC, asserting the update is rejected and the shared class-level mapping is left untouched.
• Verified existing patterns still work by exercising the module directly (couldn't run full bazel/pytest suite in this sandbox — no bazel/protoc available to generate mesop.protos.ui_pb2): nested dataclasses, lists of dataclasses, dict/nested-dict-typed fields, unannotated nested state classes with declared fields, and the existing dunder-key protection.
• CI should run the full test suite on this PR.

---

Generated by Claude Code

[Vectrain51]

Thanks for preparing this patch and the regression test.

I reviewed the change, and it addresses the remaining non-dunder class-level attribute pollution path.

As a small follow-up, please ensure the existing tests for valid nested dataclass fields and dictionary-valued state fields continue to pass, since those updates should remain supported.

Subject to the normal CI results, this looks like an appropriate fix. Thanks again for addressing the residual issue :)