Restructure the repository (backend)

[chetanr25]

As discussed in #501, we can take forward this discussion into implementation . We need to structure FireForm codebase before proceeding further to add more features.
This is the proposed codebase structure. (with minute changes)

FireForm/
  app/              # application code
  docker/               # per-environment build + compose files
  conf/                 # runtime configs (nginx, ollama, logging)
  docs/                 # short, focused markdown
  scripts/              # one-off ops/dev helpers
  tests/
  Makefile
  pyproject.toml
  README.md
  CONTRIBUTING.md  SECURITY.md  CODE_OF_CONDUCT.md  LICENSE

app/ is one Python package, layered:

app/
  api/
    routes/             # forms.py, templates.py
    schemas/            # pydantic request/response models
  services/             # llm.py, file_manipulator.py, filler.py  (was src/)
  models/               # sqlmodel/orm models
  db/                   # database.py, repositories.py, init_db.py
  core/                 # config, logging, error handlers
  utils/                # small helpers with no dependencies
  main.py               # FastAPI app factory + lifespan

docker/ is one folder per environment:

docker/
  dev/
    Dockerfile          # mounts source, --reload
    compose.yml
  prod/
    Dockerfile          # multi-stage, no source mount, gunicorn
    compose.yml

  entrypoint.sh
  README.md             # which file to use when

<some more docker compose to test out few features, or for admin etc>

Post repo-split, FireForm is the server-only repo. The Python code is split across api/ (FastAPI) and src/ (LLM/PDF engine) with names that mislead newcomers. docker/Makefile/docs all assume the old shape and the now-removed frontend. This restructures the repo into a clean, layered, reproducible server project.

This will be a very large refactor of the current repository, focused on long-term maintainability.