Skip unresolved group members during optimistic publish replay

[MaxRink]

Per the message in this thread, optimistic group publish could crash while replaying membersState if one group member no longer resolves.

This adds a defensive guard so unresolved group members are skipped with a warning instead of dereferencing undefined.ID.

Fixes #31951.

[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?