fix(sentinel): hash-pin the image's Python dependencies

The base image is already pinned by digest; the Python layer on top was not.
requirements.txt is all floating >= constraints, so two builds of the same
Dockerfile could install different code, and this is an image people build and
run from the README's docker-compose rather than something CI produces once.

requirements.txt stays as the statement of intent. requirements.lock.txt is the
resolved, hash-pinned form and is what gets installed, so a rebuild fetches the
same bytes. The compile command is in the Dockerfile next to the COPY.

Verified with pip install --dry-run --require-hashes against the lock: resolves
clean, 44 packages, and picks up cryptography 50.0.1, above the floor the
org-wide advisory work set.

This is the only unpinned install in the repo that is neither a local path nor
a deliberate published-artifact fetch. The other Scorecard pipCommand findings
here are one or the other, and are being dismissed with reasons rather than
"fixed" into something they should not be.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XbDBXDWWvMFa7c2jGgyq9t

Author: imran-siddique

integrations/sentinel/Dockerfile

@@ -2,8 +2,14 @@ FROM python:3.11-slim@sha256:9c900dea9e8fb7e16277c179b555cc72d29a352dbc33cff48ad
 
 WORKDIR /app
 
-COPY requirements.txt .
-RUN pip install --no-cache-dir -r requirements.txt
+# requirements.txt states the constraints; requirements.lock.txt is the
+# resolved, hash-pinned form and is what actually gets installed, so a rebuild
+# of this image fetches the same bytes it did the first time. Recompile with:
+#   uv pip compile integrations/sentinel/requirements.txt
+#     --generate-hashes --universal --python-version 3.11
+#     -o integrations/sentinel/requirements.lock.txt
+COPY requirements.txt requirements.lock.txt ./
+RUN pip install --no-cache-dir --require-hashes -r requirements.lock.txt
 
 COPY sentinel/ ./sentinel/
 COPY sample_trace.json .