[BUG] codepipeline: sourceRevisions is never resolved and is permanently empty (CodePipelineService.java:303)

Summary

sourceRevisions on a CodePipeline execution is only ever populated by copying it out of the inbound StartPipelineExecution request. floci never resolves the actual source artifact, so for every realistic execution the field is permanently [].

CodePipelineService.java:303:

execution.setSourceRevisions(objectList(request.path("sourceRevisions")));

That is the only write site in the codebase. CodePipelineExecution.java:29 initialises the field to an empty ArrayList, and CodePipelineService.java:1771 faithfully serialises whatever is there into GetPipelineExecution / ListPipelineExecutions responses.

Why this is wrong

In real AWS, sourceRevisions is resolved by the service at execution start from the pipeline's configured source action, independent of how the execution was triggered. For an S3 source the entry carries actionName, revisionId (the object ETag or version id), revisionSummary, and revisionUrl. Callers use it to answer the question "which artifact did this run actually consume?"

StartPipelineExecution does not accept a sourceRevisions parameter that behaves this way — the real API accepts sourceRevisions only as an override for specific source actions, and still resolves and reports the effective revision. floci treats the caller's input as the whole truth, so:

• A pipeline started by a client that sends no sourceRevisions (the overwhelmingly common case, and what AWS LZA's installer does) reports [] forever.
• There is no way for any consumer to determine which source artifact a run consumed.

Impact

Severity 5. This silently returns a wrong value for a documented response field rather than failing, so consumers cannot detect it.

Concretely: it defeats any verification gate of the form "assert this execution consumed the bytes I uploaded." We hit this building an AWS LZA v1.16.0 scenario. A pipeline run reported SUCCEEDED across all 9 stages while having consumed a substituted stub config instead of the operator's config — a false green that produced 3 accounts instead of 15. The natural gate for that class of failure is comparing the execution's source revision id against the locally computed md5 of the uploaded zip (single-part PUT means ETag = md5). That gate is unimplementable against floci because the field is always empty, and the gap is invisible until you try to use it.

Suggested fix

At execution start, resolve the source revision from the pipeline's source action configuration rather than from the request:

• Read the source action's configured bucket/key (or repository/branch).
• Look up the current object and populate revisionId from its ETag (and revisionUrl / revisionSummary).
• Apply any caller-supplied sourceRevisions as an override on top of the resolved value, matching the real API's semantics, instead of as the sole source.
• Leave [] only when the pipeline genuinely has no resolvable source.

Related: floci has no S3 source-change detection either — see the companion issue. The two share a root cause (the source artifact is never resolved) but have independent fixes, and this one is the smaller and more contained of the two.

Reproduction

1. Create a pipeline with an S3 source action.
2. Upload a source zip.
3. aws codepipeline start-pipeline-execution --name <pipeline> with no --source-revisions.
4. aws codepipeline get-pipeline-execution --pipeline-name <pipeline> --pipeline-execution-id <id>.

Expected: sourceRevisions contains one entry naming the source action with revisionId equal to the uploaded object's ETag. Actual: sourceRevisions is [].