Fix Python container builds for workspace members above the workspace root

[chrislambert]

Summary

Python container builds fail when a uv workspace member is referenced with a parent path (e.g. members = ["../../lib"]). This PR copies such members into the docker build context and rewrites the requirements.txt lines and pyproject.toml member paths so uv can resolve them inside the image.

Fixes #6928

Problem

uv export writes path members into requirements.txt as-is. A member above the workspace root produces a line like ../../lib, which breaks container builds three ways:

1. copyWorkspacePackagesForContainer copies the member to filepath.Join(artifactDir, "../../lib"). That path is outside the docker build context, so the package never reaches the image.
2. Inside the image, uv resolves ../../lib against the requirements.txt location (/var/task) and fails.
3. Even with 1 and 2 fixed, the artifact's pyproject.toml still declares members = ["../../lib"], and uv's workspace validation fails when building the project in-image: Workspace member '/var/task/../../lib' is missing a 'pyproject.toml'

Members inside the workspace root (./core) are unaffected.

Solution

In copyWorkspacePackagesForContainer:

• Members that resolve above the workspace root are re-homed inside the build context by stripping the leading ../ segments (../../lib becomes ./lib).
• Their requirements.txt lines are rewritten to the new path. Extras and markers are preserved.
• The matching member paths in the artifact's pyproject.toml are rewritten the same way, via exact quoted-string replacement so the rest of the file is untouched. The source tree is never modified.

Compatibility:

• Members inside the workspace root keep identical behavior.
• Zip builds do not run this code path.
• Every configuration this touches fails unconditionally today, so no working setup can regress.

Known limitation: literal member paths only. Parent-path globs (members = ["../../packages/*"]) are not rewritten in pyproject.toml.

Testing

• New TestCopyWorkspacePackagesForContainer: re-homing with requirements and pyproject rewrites, extras and markers preserved, ./ members unchanged, missing member directories left alone, source pyproject untouched.
• go test ./pkg/runtime/python/ passes, gofmt and go vet clean.
• Validated end to end on a real monorepo: a container Lambda whose deploy failed with this error builds, deploys, and processes SQS jobs with the patch.

[chrislambert]

@vimtor gentle nudge on this when you get a chance 🙏

Fixes #6928 — Python container builds break when a uv workspace member lives above the workspace root (members = ["../../lib"]). It's an edge case in the copyWorkspacePackagesForContainer path added in #6061: parent-path members get copied outside the Docker build context and their ../../ paths leak into the artifact's requirements.txt + pyproject.toml, so uv can't resolve them in-image (full three-way breakdown in the PR body).

Should be safe to merge on your own read — every config this path touches fails unconditionally today, so there's no working setup it can regress. Targets dev, no conflicts, and I added coverage to build_test.go.

cc @subssn21 as the author of that path in #6061 if you want a second set of eyes — no need to block on it though. Happy to adjust anything.