ConnectionServiceLayer: PostAsync, PostReOpen y PostClose comparten un nucleo (EnviarPostAsync)

Eran tres copias (94% a 97% iguales). Se verifico con un servidor simulado
que el resultado es identico al anterior en reintento por 401, 204 sin cuerpo,
rechazo y log de errores. PatchAsyncSBA no se toca.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -98,7 +98,12 @@ transferencias siempre, sin depender de `Notificacion`. Detalle y tabla en
   exactas sin llamadores: `HelperHojaRuta.GetConsolidado` (queda `HelperStock.GetConsolidado`)
   y `HRRepository.UpdateCreateCreditNotes` (queda `CreditNotesRepository`). Sigue pendiente: código
   comentado, `PatchAsyncSBA`, repositorios de compras sin uso
-  (`SetCreatePurchaseInvoices` duplicado en `PurchaseOrdersRepository`) y la redundancia de los métodos POST/PATCH del cliente.
+  (`SetCreatePurchaseInvoices` duplicado en `PurchaseOrdersRepository`) y el resto de la redundancia (serie `BC10`/`FC10` y cabecera de la NC).
+  `PostAsync`, `PostReOpen` y `PostClose` de `ConnectionServiceLayer` comparten ahora un
+  núcleo privado (`EnviarPostAsync`: con/sin cuerpo, acepta o no el 204); se verificó con un
+  servidor simulado que el resultado es idéntico al anterior (reintento por 401, 204 sin
+  cuerpo, rechazo y log). `PatchAsyncSBA` sigue aparte: su manejo de errores es distinto y
+  mantiene su bug del 204 (sin marcar éxito; el único llamador ignora el resultado).
   La transferencia automática de stock de la NC (3 copias en Picking x2 y Recibo)
   pasó a un solo método: `Net.Data/ServicesLayer/StockTransfer/TransferenciaAutomaticaNC.Crear`.
 - Sin probar contra SAP: confirmar con la factura 292410 que SAP devuelve