ADR-014: contrato gRPC de inventario alineado con buf STANDARD

Aceptado el 10/11/2026 por Andrés, antes de escribir código que use el contrato.

Contexto

make verify corre buf lint con el conjunto de reglas STANDARD, el estándar de estilo de buf para Protocol Buffers. El contrato inventory.proto incumplía tres reglas, que en F0 quedaron como excepciones explícitas en contracts/proto/buf.yaml:

Regla	Qué pide	Cómo estaba
`PACKAGE_DIRECTORY_MATCH`	La carpeta sigue al paquete	Paquete `andesretail.inventory.v1` en la carpeta `inventory/v1`
`RPC_REQUEST_RESPONSE_UNIQUE`	Cada RPC con su propio mensaje de respuesta	`Confirm`, `Release` y `GetReservation` compartían `ReservationResponse`
`RPC_RESPONSE_STANDARD_NAME`	La respuesta se llama `<Rpc>Response`	`ReservationResponse` no corresponde a ningún RPC

Ningún servicio usa todavía el contrato: cambiarlo hoy no cuesta nada; cambiarlo después de F4 obliga a regenerar código y a versionar.

Opciones

Mantener las excepciones. Sin trabajo ahora; el contrato queda fuera del estándar y una respuesta compartida acopla tres operaciones.
Ajustar el contrato al estándar. Un cambio pequeño, sin efecto en el diseño.

Decisión

Opción 2:

El archivo pasa a contracts/proto/andesretail/inventory/v1/inventory.proto. Paquete y java_package no cambian.
Confirm devuelve ConfirmResponse, Release devuelve ReleaseResponse y GetReservation devuelve GetReservationResponse. Las tres llevan hoy el mismo campo Reservation reservation = 1.
buf.yaml usa STANDARD completo, sin excepciones.

La semántica del diseño (docs/to-be/03-stock-vendible-y-reservas.md) no cambia: mismas operaciones, misma idempotencia por order_id, mismos estados.

Qué se sacrifica

Tres mensajes casi idénticos en lugar de uno. A cambio, cada respuesta puede crecer sola (por ejemplo, el motivo de un EXPIRED en Confirm) sin tocar a las demás.
La ruta del contrato es más larga.