Make local uv dependencies hermetic in Python container builds

[achadha235]

Fixes #6964 and #6928

Problem

Python container artifacts previously preserved local paths from uv export. Those paths are valid in the source checkout but not necessarily in the Docker build context. This includes the ../../member cases reported in #6928 and custom Dockerfiles that install local dependencies before their source is available. This also affects custom Dockerfiles that copy the full SST artifact before installation. Since the artifact is not a copy of the original uv workspace layout, running uv sync or regenerating requirements inside the image failed to resolve workspace dependencies.

Solution

For container builds, SST now:

• resolves each local requirement in the original workspace;
• builds it as a PEP 517 source distribution under .sst/packages/;
• rewrites requirements.txt to reference that artifact-local archive; and
• lets uv install the archive inside the Lambda Linux image.

This keeps the generated artifact self-contained and avoids recreating or rewriting the user's uv workspace layout inside Docker.

materializeContainerRequirements reads and rewrites the exported requirements file. rewriteContainerRequirements resolves and deduplicates local paths while preserving extras and environment markers. buildContainerSdist writes each package archive below the artifact root.

Why this approach

I believe this is a more robust solution than #6929 because it packages the resolved local dependencies instead of recreating the source workspace inside Docker by copying directories and rewriting relative paths. That keeps the artifact independent of the developers layout and avoids requiring uv to reconstruct the workspace from a partial build context.

Testing

Tests cover parent-path workspace members, descendant path dependencies, duplicate local dependencies, extras and markers, missing packages, and artifact-path containment.

I've added a test build at my fork achadha235/sst yellowbrick-sst-v0.1.0 for validating the change against existing Python setups before merge. I've already used this in production with my own project and it seems to be working well.

@chrislambert @subssn21 I'd appreciate if you could have a look and validate against your own Python SST setups