[BUG]: Stale template records cause 500 errors after re-clone or file move

[utkarshqz]

⚡ Describe the Bug

Template records stored in the SQLite database (fireform.db) contain absolute file paths to PDF files on the original machine. After re-cloning the repository, moving the project directory, or onboarding on a new machine, all existing template records point to non-existent paths.

This causes silent failures or 500 Internal Server Error on POST /forms/fill with no clear error message.

---

📉 Expected Behavior

Template records should either:

• Store relative paths anchored to the project root
• Validate that the referenced PDF exists on disk when a template is loaded

---

🕵️ Steps to Reproduce

1. Clone the repository and set up FireForm on Machine A
2. Upload a PDF template via POST /templates/upload
3. Re-clone the repository on Machine B (or move the project folder)
4. Attempt POST /forms/fill with a previously registered template
5. Observe: 500 Internal Server Error

---

🩹 Temporary Workaround

Reset the database manually:

python -c "
import sqlite3
c = sqlite3.connect('fireform.db')
c.execute('DELETE FROM template')
c.execute('DELETE FROM formsubmission')
c.commit()
print('Database cleared.')
"

---

💡 Proposed Fix

1. Store template PDF paths as relative paths from project root (e.g. src/templates/fire_dept.pdf) instead of absolute paths
2. Add path existence check in the template repository layer
3. Add a scripts/reset_db.py helper script
4. Document this behaviour clearly in SETUP.md

---

✅ Acceptance Criteria

• Template paths stored as relative paths
• Validation on template load — clear 404 if PDF missing
• scripts/reset_db.py utility added
• SETUP.md updated with database reset instructions
• New contributor setup works cleanly on a fresh clone