Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts" line_range="4602" />
<code_context>
+    }
+
+    // emitOwnEvents is off, so Baileys will not echo this change back to us.
+    await this.contactHandle['contacts.update']([{ id: pnJid, name: data.fullName }]);
+
+    // Chats that arrived addressed to the LID keep their own contact row.
</code_context>
<issue_to_address>
**Accepted updates leave contacts stale**

When baileys accepts the patch, then the profile-picture lookup, event adapter, or PN contact write in `contacts.update` fails, `updateContact` propagates the `contacts.update` failure after `addOrEditContact` has accepted the WhatsApp change, so the API returns an error while the local contact remains stale; a profile-picture lookup failure also prevents the webhook from being sent.

Make local synchronization failure-safe after the remote patch, retrying or reconciling failed contact updates instead of leaving the accepted change stale.
</issue_to_address>

### Comment 2
<location path="src/validate/chat.schema.ts" line_range="327" />
<code_context>
+  type: 'object',
+  properties: {
+    number: { type: 'string' },
+    fullName: { type: 'string' },
+    firstName: { type: 'string' },
+    saveOnPrimaryAddressbook: { type: 'boolean' },
</code_context>
<issue_to_address>
**Long names fail local persistence**

When `fullName` exceeds 100 characters and contact persistence is enabled, the schema accepts the name, but the Contact `pushName` column is limited to 100 characters. Baileys accepts the patch before Prisma rejects the local write, so the request fails and the local contact remains stale.

Set a 100-character maximum for `fullName` in `updateContactSchema`.
</issue_to_address>

### Comment 3
<location path="src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts" line_range="4602" />
<code_context>
+    }
+
+    // emitOwnEvents is off, so Baileys will not echo this change back to us.
+    await this.contactHandle['contacts.update']([{ id: pnJid, name: data.fullName }]);
+
+    // Chats that arrived addressed to the LID keep their own contact row.
</code_context>
<issue_to_address>
**Saved avatars disappear**

When a contact has a saved avatar and the profile-picture lookup during a name update fails or returns null, `contacts.update` writes the null `profilePicture` result into `profilePicUrl`, replacing the saved avatar, so contact listings lose it.

Preserve the existing `profilePicUrl` when the lookup fails or returns null.
</issue_to_address>

### Comment 4
<location path="src/validate/chat.schema.ts" line_range="332" />
<code_context>
+    saveOnPrimaryAddressbook: { type: 'boolean' },
+  },
+  required: ['number', 'fullName'],
+  ...isNotEmpty('number', 'fullName'),
+};
+
</code_context>
<issue_to_address>
**Empty names are accepted**

When the request includes an unrecognized property or an optional field and `fullName` is empty, `isNotEmpty` skips the `minLength` check when a property name is outside its enum, so the empty `fullName` reaches `addOrEditContact` and leaves the contact with a blank name.

Validate that `fullName` is nonempty independently of the other request properties.
</issue_to_address>

### Comment 5
<location path="src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts" line_range="4602-4610" />
<code_context>
+    }
+
+    // emitOwnEvents is off, so Baileys will not echo this change back to us.
+    await this.contactHandle['contacts.update']([{ id: pnJid, name: data.fullName }]);
+
+    // Chats that arrived addressed to the LID keep their own contact row.
+    if (lidJid && this.configService.get<Database>('DATABASE').SAVE_DATA.CONTACTS) {
+      await this.prismaRepository.contact.updateMany({
+        where: { remoteJid: lidJid, instanceId: this.instanceId },
+        data: { pushName: data.fullName },
+      });
+    }
+
+    return { update: 'success', remoteJid: pnJid, lid: lidJid, fullName: data.fullName };
</code_context>
<issue_to_address>
**PN and LID names diverge**

When the PN update succeeds but the separate LID contact update fails, the PN row is committed while the LID row retains the old name, so LID-based contact reads remain stale and the caller receives an error despite the accepted WhatsApp patch.

Make the PN and LID contact updates atomic, or retry/reconcile a failed LID update.
</issue_to_address>