Quitar el prefijo home_ de las 41 tablas del portal

El prefijo venía del nombre de la app Django (`home`), jubilada y borrada hoy,
así que ya no significaba nada: home_stripelog -> stripelog. La BD se sigue
llamando django_wow por historia (renombrarla es otra operación).

Comprobado antes de tocar nada: 0 colisiones con nombres existentes, 0 palabras
reservadas (contrastado contra las 260 de MySQL), sin vistas ni triggers que
dependieran de ellas. El RENAME va en una sola sentencia porque así es atómico,
y MySQL reapunta solo las 4 claves ajenas entre estas tablas.

170 referencias actualizadas en 37 ficheros. Se dejó a propósito
sql/drop_home_securitytoken_authuser_fk.sql sin tocar: es una migración ya
aplicada y reescribirla sería falsear el historial.

De paso salió un fallo previo: prices.ts consultaba `home_restoreitemprice`,
una tabla que NO existe. El try/catch de priceFrom se comía el error y devolvía
siempre el precio por defecto, así que el precio de restaurar objetos nunca fue
configurable. Se deja documentado en el código; crear la tabla es otra decisión.

Verificado tras aplicar: 0 tablas home_, las 51 siguen ahí, y el conteo exacto
de filas cuadra con el volcado previo (store_item 3068, item_data 44873,
stripelog 35, store_order 26, noticia 50). La web responde 200 en todas las
rutas y la portada carga las noticias sin errores.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

web-next/lib/store-pricing.ts

@@ -25,7 +25,7 @@ export const CARD_MIN_EUR: Record<'stripe' | 'sumup', number> = {
 /**
  * Máximo de copias de un mismo ítem por línea del carrito (igual que el MAX_QTY
  * de send-gift). OJO con la diferencia: `copies` es cuántas VECES compras la
- * línea, y no se confunde con `home_store_item.quantity`, que es el tamaño del
+ * línea, y no se confunde con `store_item.quantity`, que es el tamaño del
  * lote que entrega cada copia (Paño de lino = 20). 2 copias de Paño de lino =
  * 40 telas, y se envían como dos entradas `2589:20`.
  */