Pin the rest of requirements.txt so a rebuild can't shift the stack silently

[gaurav]

#294 was caused by fastapi being unpinned: the image built for v1.7.0 picked up 0.137.0, which
stopped honouring app.openapi_schema, and the service shipped a valid-but-wrong OpenAPI document
without anything failing. That pin is now fastapi~=0.141.1.

Everything else in requirements.txt is still unpinned and can move the same way under an unrelated
rebuild:

requests
httpx
uvicorn
pyyaml
jsonlines
pytest

httpx is the one that matters most — it is how the API talks to Solr — but any of them can change
between a passing CI run and the image ITRB deploys, since the two install at different times from
the same unpinned list.

Needs a decision on approach rather than a quick edit:

• Pin everything at compatible-release (~=) versions, as fastapi and the opentelemetry packages
  now are?
• Or generate a fully-pinned lockfile (pip-compile / uv pip compile) from a loose top-level list,
  which also makes CI and the image install identical sets?
• Either way, how do the pins get bumped on a schedule so they don't rot into a stack we can't
  upgrade?

Related: the opentelemetry packages are already hard-pinned at 1.27.0 / 0.48b0, which is old
enough to be worth reviewing as part of this.