fix(python-uv): pass --no-default-groups to uv export

[tomaDev]

Issue

PythonUvDependencyBuilder._build_from_lock_file invokes `uv export` without `--no-default-groups`. Newer `uv` (≥ ~0.5) treats `tool.uv.default-groups` as `["dev"]` by default — so any project using the PEP 735 `[dependency-groups]` standard with a `dev` group has its dev/test dependencies (`moto`, `pytest`, `cryptography`, `docker`, …) silently rolled into the exported requirements and shipped into the resulting Lambda zip.

Measured impact on a project with 9 functions on python3.14 / arm64:

	before	after
.aws-sam/build total	588 MB	114 MB
ApiFunction zip	98 MB	31 MB
cold `uv pip install` per function	144–208 s	14–45 s

Fix

Add `--no-default-groups` to the `uv export` invocation in
`aws_lambda_builders/workflows/python_uv/packager.py`. Lambda zips are
runtime artifacts — they should never carry dev/test groups.

Users who want a specific group bundled can still declare it under
`[project] dependencies` or explicitly listed dependencies; default
groups are exactly what should be excluded from a deployable artifact.

Test

Extended `test_build_dependencies_pyproject_with_uv_lock` to assert
`--no-default-groups` is present in the export args. Test fails without
the source change (verified by temporarily removing the line locally:
`AssertionError: '--no-default-groups' not found in [...]`) and passes
with it.

Compatibility

`--no-default-groups` has been available in `uv` since the
introduction of the dependency-groups feature (well before `uv` 0.5).
Older `uv` versions without PEP 735 support simply ignore the flag (no
default groups to skip). No new flag is added to the AWS Lambda
Builders API; behavior change is contained to the implicit zip
contents — which already silently changed when `uv` began including
default groups in exports.

[reedham-aws]

Good find and thank you for raising this!

[reedham-aws]

The test failures are unrelated to your change and I think related to incompatibility between certain node and npm like was fixed in #862. I haven't looked but this seems like the issue.

[tomaDev]

The test failures are unrelated to your change and I think related to incompatibility between certain node and npm like was fixed in #862. I haven't looked but this seems like the issue.

Yes, from a brief look it seems to be an unrelated block. How to move forward here?

[tomaDev]

@reedham-aws friendly bump 🙂 — this has your approval and the only red checks are the known-unrelated windows / esbuild / node 24 / npm 9.x|11.x matrix failures (same node/npm incompat as #862); all python-uv jobs are green.

Anything outstanding on my side to land this — a second reviewer, or do the unrelated Windows failures need excluding/addressing first? Happy to rebase on main to re-trigger CI if useful. Thanks!

[reedham-aws]

@tomaDev, sorry for the delay, I'll take a look at fixing the changes, and then we can get this merged after a merge from mainline into your branch (which could be done from GitHub UI).

I know you have another PR, I'll take a look at that one as well.

[reedham-aws]

Actually, it looks like it's just a flaky issue that happened at the time, the error message from npm isn't even showing anything. I think there's a race condition in the test, but since it's not relevant to this PR it's fine to merge.