Python container builds fail when a uv workspace member lives above the workspace root #6928

Python container functions fail to build when the uv workspace references a member with a parent path:

[tool.uv.workspace]
members = ["../../lib"]

This layout is common in monorepos where several independent uv workspaces share one library package. Members inside the workspace root (./core style) work fine.

Symptom

The docker build fails at the dependency install step:

RUN uv pip install -r requirements.txt --target ${LAMBDA_TASK_ROOT} --system
exit code: 2

Cause

uv export writes the member into requirements.txt as ../../lib. Three things then go wrong in container builds:

1. copyWorkspacePackagesForContainer copies the member to filepath.Join(artifactDir, "../../lib"), which lands 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. The pyproject.toml copied into the context still declares members = ["../../lib"], which fails uv workspace validation when building the project in-image: Workspace member '/var/task/../../lib' is missing a 'pyproject.toml'

Repro layout

repo/
  lib/                  # shared package
  projects/app/         # uv workspace root
    pyproject.toml      # members = ["../../lib"]
    src/handler.py

with a python.container: true function whose handler lives in projects/app.

I have a tested fix and will open a PR: copy such members into the build context with the leading ../ segments stripped, and rewrite the requirements.txt line and pyproject.toml member paths to match. No change for ./ members or zip builds, and every configuration this touches fails unconditionally today.