Skip unresolved group members during optimistic publish replay

[MaxRink]

Optimistic group publish can crash when a member returned in membersState no longer resolves.

Use the existing membersDevices() iterator when collecting group state, and skip unresolved entities during optimistic replay. The regression test verifies that resolved members still publish and the missing member produces no warning.

[Koenkk]

replaying membersState if one group member no longer resolves.

I'm wondering how this can happen? Sounds like inconsistency in the database.db, can you reproduce this?

[luantaraschi]

I found one mismatch between the patch and the issue it claims to fix. In the Zigbee2MQTT 2.10.1 source referenced by #31951, line 192 is endpointOrGroupID = localTarget.ID. The reported Shelly failure therefore occurs after re.endpoint(endpointName) returns undefined. This patch and its regression test exercise a different path: scene_recall on a group with an unresolved entry in converter-produced membersState.

I ran the new targeted test and pnpm run check; both passed. The defensive group handling looks consistent, but the test does not reproduce the switch_type_sw1 or switch_mode_sw1 failure from #31951. Could you either add a reproduction for that Shelly endpoint path, or remove Fixes #31951 and link this change to the unresolved-group scenario it covers?

[luantaraschi]

The description has drifted from the code. It still says unresolved members are "skipped with a warning", but after the rework the guard just skips, and the new test asserts the warning count is zero. Worth bringing the body in line, since that sentence is what a reviewer reads before the diff.