[MIG] product_state: migración a Odoo 20 (#12994)

[CILC98]

Riesgo: bajo

• Tipo: datos
• Descripción:

  Migra product_state (módulo vendorizado de OCA/product-attribute) de 18.0 a Odoo 20.
  Deltas aplicados: version a '1.0'; security/ir.model.access.csv -> security/ir.access.csv
  (esquema nuevo de ir.access, sin filas con group_id vacío así que no aplica la trampa de
  polaridad); _sql_constraints -> models.Constraint; product.state._compute_products_count
  reescrito sobre _read_group(..., aggregates=['__count']) porque el read_group() clásico
  (domain, fields, groupby -> dict) ya no existe con esa firma en v20 (delta no documentado
  todavía en el rulebook, harvest en PR aparte a TRESCLOUD/ci); el <header> de
  product.product_template_form_view desapareció por completo de su cadena de herencia en v20
  (verificado: cero <header> en toda la herencia), así que se re-ancla creando el <header>
  propio antes del <sheet> (mismo resultado visual, statusbar clickeable); icono del stat button
  fa-cubes -> inventory_2 (FontAwesome eliminado; mismo icono que usa stock/mrp para
  conteos de producto); t-esc -> t-out en el kanban card (motor QWeb del servidor ya no
  soporta t-esc/t-raw, verificado cero ocurrencias fuera de static/src/ en todo el core v20).

  Nota sobre manifest (license/author/support): product_state es un módulo OCA
  (autor ACSONE SA/NV, licencia AGPL-3), vendorizado en este fork para la línea v20 — no es
  propiedad de Trescloud. Se mantiene license='AGPL-3' y la autoría original de OCA (relicenciar
  a OPL-1 o atribuir autoría a Trescloud sería incorrecto/no legal). El quality_gate marca
  ❌ en license/author/support porque asume módulos propios de Trescloud; se acepta como
  excepción documentada para este módulo vendorizado (decisión confirmada con el dev). Se agregó
  maintainer='Odoo Community Association (OCA)' y development_status='Beta'.

  Nota sobre la base de la rama: esta rama parte de pre-20 local, que a su vez incluye 2
  commits previos del mismo autor aún no sincronizados con origin/pre-20
  (Remove OCA tier-validation submodules not in v20 migration scope y
  [ADD][CL] Añadir módulos necesarios para migrar, que agrega product_state y
  product_tier_validation al fork) — por eso aparecen también en este diff.

  Métricas: install+test verde en 3 iteraciones (1: <header> no resuelve, re-anclado;
  2: sin --with-demo el test de setUpClass falla por xmlid demo faltante — delta de v20,
  demo pasa a ser opt-in; 3: verde). Resultado final: 7 tests, 0 failed, 0 error(s), módulo
  queda installed (confirmado por SQL). 5 archivos modificados + 1 renombrado
  (ir.model.access.csv -> ir.access.csv).

Validación de flujos

Cubierto por tests automáticos (tests/test_product_state.py, 7 tests, 0 failed, 0 error(s)):

• Producto existente recibe el estado default vía post_init_hook; un estado nuevo arranca sin productos.
• Crear un producto sin estado explícito -> queda con el estado default (sellable).
• Crear un producto con estado explícito -> queda con ese estado; el contador products_count del estado sube a 1.
• Escribir el código de estado (product.state = "Code") actualiza product_state_id (inverse).
• Constraint: no puede haber dos estados default=True a la vez.
• Escribir un código de estado inválido levanta UserError.
• Copiar un producto no-default -> la copia vuelve al estado default.

Flujos clave sin test automático (UI, no cubierto por TransactionCase):

• Statusbar de estado en el form de producto (el <header> re-anclado): abrir cualquier producto,
  confirmar que el statusbar de "State" se ve arriba del formulario y es clickeable para cambiar de estado.

  [pega aquí tu evidencia]

• Smart button "Products" en el form de product.state (icono inventory_2): abrir un estado desde
  Ajustes/Inventario, click en el stat button, confirmar que abre la lista de productos filtrada por ese estado.

  [pega aquí tu evidencia]

• Vista kanban de product.state (el t-out del contador): abrir la vista kanban de estados de producto,
  confirmar que el número de productos se ve (no en blanco) en cada card.

  [pega aquí tu evidencia]

• Permisos por grupo (Product State Manager CRUD completo / usuario interno solo lectura / público
  solo lectura): probar con un usuario de base.group_user sin el grupo manager, confirmar que puede
  leer pero no crear/editar estados.

  [pega aquí tu evidencia]

• Número Ticket/Tarea: #12994
  EOF
  echo "guardado en /tmp/claude-1000/-home-user-Escritorio-Repositorio-erramientas-src-v20/713c0210-a357-4b6b-8ddc-3bf3ef1cbb83/scratchpad/pr_body_product_state.md"