feat: branch betos — propiedades, oferta de proveedores, chat en contratos y flujo de postulacion renovado

- Sistema de propiedades: tabla, modelo, CRUD API para que el cliente guarde direcciones nombradas
- Postulacion renovada: cliente elige propiedad sin precio ni fecha, sube fotos a GCS/S3
- Proveedores ofertan date_1, date_2 y amount al postularse via pivot; sort por fecha/monto/membresia
- Contratacion: selected_date recibe date_1 o date_2, amount desde pivot (depreca minimun_fee)
- Cancelacion/repostulacion: archive con status=perdido, related_postulation_id para vincular
- Chat en contratos activos: tabla contract_comments, controller, rutas web+API, vista panel, notificaciones bilingues
- PaymentIntent calcula amount desde pivot en vez de recibirlo del front
- getpendingcontracts: sin filtro de tiempo, filtra por status=active, agrega time_created
- Expiracion de postulaciones reducida a 1000 min

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

betos_branch.md

@@ -0,0 +1,14 @@
+Este documento tiene notas tanto para back como para front. El backend está hecho en Laravel y el front en Ionic, adecua las notas a tu área correspondiente. Los cambios a continuación son bastante radicales, asi que sugiero crear un branch que se llame “betos” para trabajar esto.
+
+Los clientes deben de tener una tabla de propiedades (properties), que guarda las direcciones de sus propiedades (con coordenadas y numero exterior). Esto va a ser un cambio en category.ts, porque ahora donde dice Dirección va a ser Propiedad, con un listbox que se alimente de las propiedades ligadas al usuario de la siguente forma “Nombre de la propiedad: Dirección”, si no hay ninguna o el servicio no es para ninguna de estas, debe de abrirse el modal “Agregar Propiedad”, que pida la dirección (con autocomplete), guarde las coordenadas y el numero exterior (inputs hidden igual que en category.ts), y la guarde con un nombre personalizado asignado por el usuario (E incluso le puede poner un icono para designar si es casa u oficina).
+
+Para las postulaciones vamos a tener cambios radicales; ahora el cliente solo pondrá la categoría, la propiedad y comentarios cuando quiera postular un servicio. Adiós a definir un precio y fecha. También es importante que el cliente pueda adjuntar fotos de lo que necesita que se repare o se instale.
+
+Cuando el proveedor se postula a una postulación, debe definir una fecha en la que puede realizar el servicio y a que costo (ojo, la cuota mínima a nivel sistema se mantiene). Nota para back: eso también quiere decir que ahora ya no debe de haber un mínimum fee en la tabla de suppliers, y que la tabla pivote postulations_suppliers debe de guardar al menos dos fechas tentativas en las que puede dar el servicio y el monto que desea cobrar por el servicio.
+
+En viewsuppliers el cliente debe de poder filtrar a los postulantes por fecha más pronta en la que se puede realizar el servicio, monto más barato y si el proveedor está certificado. Definir si es más fácil hacer estos sorts en front o en back
+
+Una vez que la postulación se vuelva un CurrentContract, debemos de implementar la posibilidad de que el cliente y el proveedor se comuniquen dentro de la app de la misma manera que lo hacen en ReportDiscussion. Nota para back: Hay que agregar un botón en los Contratos Actuales que te permita ver la discusión de cada contrato y los detalles del contrato igual que lo hacemos ya en los Reportes.
+
+Por último, con estos nuevos cambios se vuelve complicado determinar como manejaremos el NoHome, si tienes alguna idea eres libre de comentar.
+Dime si estoy omitiendo algo que sea importante o nos pueda dar problemas.