[davidpp09]

El repartidor no podía ver el menú ni descargarlo: la vista previa salía en blanco y el botón respondía "popups / new tab disabled".

Una sola causa, dos síntomas

La pantalla bajaba el PDF con axios y lo volvía un blob:. En el WebView de Android —que es lo que corre dentro de Fully Kiosk— eso falla de dos maneras:

Síntoma	Por qué
Vista previa en blanco	El WebView no trae visor de PDF. El <iframe> no dibujaba nada y no había error en ninguna parte.
"popups disabled" al descargar	Una descarga desde blob: no dispara nunca el DownloadListener del WebView, y el clic acaba contando como ventana nueva. Las tablets tienen enablePopups: false.

Las tablets además llevan disableContextMenu: true y showShareButton: false, así que tampoco había forma de guardar con pulsación larga. Esos ajustes son a propósito: la tablet es un kiosko, no un navegador. Este PR no toca ninguna tablet — arregla la aplicación para que funcione dentro del kiosko tal como está.

Qué cambia

• GET /menu-dia/imagen — el mismo PDF rasterizado a PNG con PDFRenderer (150 DPI). PDFBox ya estaba, no hay dependencia nueva. Una imagen se dibuja en cualquier navegador. El PDF sigue siendo lo que se descarga e imprime, que es vectorial.
• Descarga por URL normal con token de vida corta. POST /menu-dia/enlace-descarga (autenticado) devuelve /menu-dia/descargar?t=…. Hace falta porque el gestor de descargas de Android pide el archivo por su cuenta y no manda la cabecera Authorization.

Lo que hay que mirar con lupa

GET /menu-dia/descargar es la única ruta de la API sin JWT aparte de /login, /actuator/health y el WebSocket. La credencial es el token de la query:

• aleatorio de 256 bits con SecureRandom, 43 caracteres en Base64;
• vive 3 minutos;
• solo abre el menú del día — el mismo papel que se le entrega a los clientes. No da acceso a nada más.

No es de un solo uso a propósito: el gestor de descargas de Android puede repetir la petición (reintento, o un HEAD antes del GET), y con un solo uso la descarga se vería rota sin motivo aparente. Se acotó por tiempo, que es lo que de verdad limita la exposición. Hay un test que deja esa decisión escrita para que nadie la "arregle" sin saber qué rompe.

Tests

6 nuevos, suite de 80 a 86:

• que el PNG salga de verdad (firma del archivo), se pueda releer como imagen y no salga una miniatura ilegible;
• las cuatro formas de que un token no deba entrar: inventado, vacío, nulo y vencido;
• que dos emisiones no coincidan y que el token no se haya acortado.

No lleva test de MockMvc porque el proyecto no tiene ninguno y no me pareció que un arreglo fuera el lugar para introducir ese andamiaje. La lógica nueva está cubierta; lo que queda sin cubrir es el cableado del controlador.

Sin probar en staging

restfood-staging.sh datos está roto desde el endurecimiento del 27 de julio: restfood_backup solo puede crear y borrar restaurante_ensayo, no restaurante_staging, y esa base ya no existe. Va aparte, no en este PR.

Va con RestFoodF#12. Los dos tienen que desplegarse juntos: la pantalla nueva pide rutas que solo existen con este backend.