Null-check reply allocations in allocErrorResponse and RemoteHardware (#11260)

allocAckNak returns nullptr when the packet pool is exhausted, but allocErrorResponse passed the result straight to setReplyTo, which dereferences it. Reachable unauthenticated: an ADMIN_APP packet on a known-key channel takes the NOT_AUTHORIZED path, so a flood that empties the pool crashes the node. MemoryDynamic::alloc no longer aborting on failure made this reachable on PSRAM, STM32WL and Portduino targets. Callers already treat a null reply as no response. Same fix for the two RemoteHardwareModule sites.

src/mesh/MeshModule.cpp

@@ -87,6 +87,8 @@ meshtastic_MeshPacket *MeshModule::allocErrorResponse(meshtastic_Routing_Error e
     uint8_t channelIndex =
         p->which_payload_variant == meshtastic_MeshPacket_decoded_tag ? p->channel : channels.getPrimaryIndex();
     auto r = allocAckNak(err, getFrom(p), p->id, channelIndex);
+    if (!r) // pool exhausted; callers treat a null reply as "no response"
+        return nullptr;
 
     setReplyTo(r, *p);
 

src/modules/RemoteHardwareModule.cpp

@@ -103,8 +103,10 @@ bool RemoteHardwareModule::handleReceivedProtobuf(const meshtastic_MeshPacket &r
             r.gpio_value = res;
             r.gpio_mask = p.gpio_mask;
             meshtastic_MeshPacket *p2 = allocDataProtobuf(r);
-            setReplyTo(p2, req);
-            myReply = p2;
+            if (p2) {
+                setReplyTo(p2, req);
+                myReply = p2;
+            }
             break;
         }
 
@@ -149,7 +151,8 @@ int32_t RemoteHardwareModule::runOnce()
                 r.type = meshtastic_HardwareMessage_Type_GPIOS_CHANGED;
                 r.gpio_value = curVal;
                 meshtastic_MeshPacket *p = allocDataProtobuf(r);
-                service->sendToMesh(p);
+                if (p)
+                    service->sendToMesh(p);
             }
         }
     } else {