[FEAT]: Enable parallel form submission with background worker and queue

[marcvergees]

📝 Description

Currently, the backend processes submissions sequentially, waiting for each PDF to be generated after triggering Ollama before accepting new submissions. This creates a bottleneck that prevents concurrent form processing. We need to implement a background worker and queue system to enable multiple submissions to be processed in parallel while maintaining the ability to fill multiple forms with the same input data across different template IDs.

💡 Rationale

Ollama takes significant time to generate responses, and the current synchronous architecture blocks the system from accepting new submissions until the PDF is fully created. This severely limits user experience and system throughput. By implementing an asynchronous worker pattern, we can:

• Accept multiple submissions concurrently
• Process different form templates in parallel
• Improve overall system responsiveness and capacity
• Allow users to submit multiple forms with the same input data targeting different template IDs

🛠️ Proposed Solution

Implement a distributed task queue system (e.g., Celery) with a background worker to handle asynchronous PDF generation:

• Set up worker infrastructure (Celery or equivalent)
• Create task queue for PDF generation jobs
• Modify backend API to accept and queue multiple submissions without blocking
• Implement batch processing to fill multiple templates with same input for different IDs
• Add task status tracking and result retrieval endpoints
• Update requirements.txt with worker dependencies
• Integrate Ollama trigger into worker tasks

✅ Acceptance Criteria

How will we know this is finished?

• Multiple submissions can be created and queued without waiting for PDF completion
• Each template can be filled with the same input for multiple different IDs concurrently
• Worker processes tasks asynchronously and generates PDFs successfully
• API returns submission status and allows tracking of queued/processing tasks
• Existing single-submission workflow remains functional
• Feature works in Docker container
• Documentation updated in docs/ with worker setup and usage
• Queue and worker logs are accessible for debugging

📌 Additional Context

The implementation should consider:

• Queue broker selection (Redis, RabbitMQ, etc.)
• Worker scaling and deployment strategy
• Error handling and retry logic for failed PDF generations
• Monitoring and visibility into queue depth and worker status