test(lambda): restore RIC invoke-lifecycle coverage in CI

[Eren-Jeager123]

Problem

No Lambda test exercises the invoke path. Every suite runs as docker run --entrypoint python -m pytest, which replaces ENTRYPOINT ["/lambda_entrypoint.sh", "python", "-m", "awslambdaric"] — so awslambdaric never boots. We cover imports, CUDA, GPU inference and S3 streaming, but not the RIC. The baked serving handlers have no coverage, and test_lambda_runtime.py asserts only that register_pre_fork is callable, not that it runs.

#6809 removed the tests that did cover this. Both were built around AWS_LAMBDA_CONCURRENCY_MODE and gated on the preview configs, so both would have gone inert anyway once the preview images were dropped — CI would have reported green while running nothing.

What this adds

Two tiers, because they fail in different ways.

1. Emulator (ric_concurrency_check.sh) runs the real chain — entrypoint shim → aws-lambda-rie → python -m awslambdaric → handler — against the two shapes awslambdaric 4.1.0 has:

Shape	Env	Expected
multi	AWS_LAMBDA_MAX_CONCURRENCY=N	exactly N forked workers, pre-fork hooks run
ondemand	unset	one worker, no pre-fork hooks

"Exactly N" comes from the RIC: run_concurrent() runs _before_fork (importing the handler and calling get_pre_fork() hooks in the parent), then forks exactly max_concurrency multiprocessing.Process workers.

2. Real Lambda (platform/run_platform.py) creates a function from the image under test, on managed instances with a GPU, and invokes it. This reaches what the emulator cannot: the real control plane, real instance provisioning, and the concurrency shape as configured through the API rather than an env var.

Asserted on both tiers: echo round-trip; awslambdaric/boto3/engine imports from handler code reached via an invoke; N concurrent invokes on N distinct workers; register_pre_fork ran in the parent; and for engines, N concurrent real inferences against exactly one shared GPU process.

The hook check is stronger than file existence — the hook writes its own PID and the worker asserts marker_pid == os.getppid(), proving it ran in the parent before the fork.

ric_probe_handler.py is shared by both tiers and is deliberately not named test_*.py so pytest does not collect it. platform/Dockerfile.test bakes it into the image, because Lambda cannot bind-mount a handler.

Validation

GPU paths run in this PR's validation-test. RIC mechanics were verified locally first on a CPU image built to the same entrypoint contract, with real aws-lambda-rie and real awslambdaric==4.1.0 — 9/9 checks passed. Negative control: stripping the @register_pre_fork block makes the hook check fail and the script exit 1, so the assertion is not vacuous.

The real-Lambda driver was run end to end against an actual function on managed-instance GPU capacity before this PR: function created, published, environment provisioned, then echo round-trip, imports through the invoke path, 2 concurrent invokes on 2 distinct workers, and the pre-fork hook confirmed in the parent.

That run established several API details worth recording, since each one failed first:

• ExecutionEnvironmentConcurrencyConfig is rejected for managed-instance functions. Per-environment concurrency comes from PerExecutionEnvironmentMaxConcurrency inside CapacityProviderConfig, and the platform injects AWS_LAMBDA_MAX_CONCURRENCY from it. There is no ConcurrencyMode knob on this compute type.
• GpuConfig is no longer accepted; the field is AcceleratorConfig, and AcceleratorMemorySize must be one of 3, 6, 12, 16, 24 or 48 GB.
• A GPU capacity provider rejects a function that declares no accelerator requirement.
• A new function settles into ActiveNonInvocable. It becomes invocable only after PublishVersion with PublishTo=LATEST_PUBLISHED, publishing is rejected until LastUpdateStatus reports Successful, and invokes then target the $LATEST.PUBLISHED qualifier.
• Omitting PerExecutionEnvironmentMaxConcurrency does not pin one worker per environment — 2 concurrent invokes were still served by 2 workers. The worker-count assertion therefore applies to the multi shape only, which is the driver's default.

Notes for review

• CI time: engine configs pay two engine cold starts on the emulator tier, one per shape. The real-Lambda tier adds one function lifecycle, mostly instance provisioning (~3-4 min observed).
• Capacity: no GPU instance available exits 2, which the job turns into a warning rather than a release-blocking failure. A genuine assertion failure exits 1 and blocks.
• The managed-instance API fields are absent from the bundled botocore, so the driver signs its own requests with SigV4 rather than shipping a service model. Post-GA that collapses to boto3.client("lambda").
• The RIE returns HTTP 200 even when the handler raises (error in the body), so every emulator check validates a real JSON field rather than the status code. Worth preserving.
• DOCKER_GPU_FLAG can be set empty to run the emulator check on a CPU box.
• The real-Lambda job is wired in the PR workflows under the same condition as the GPU validation tests, so unrelated changes do not consume GPU capacity.
• Drive-by: runai_s3_check.sh referenced the deleted rie_topology_check.sh.

[Eren-Jeager123]

DONT MERGE