Update XML serialization for unions to properly handle unit struct members

[landonxjames]

Motivation and Context

Fixing two CI issues that recently popped up. See https://github.com/smithy-lang/smithy-rs/actions/runs/17771171675/job/50511115119#step:4:1340 for a CI run that exhibited both failures.

Codegen Bug

Fixes a bug in XmlBindingTraitSerializerGenerator.kt exposed by a change to the S3-Control model .
The model change introduced a smithy union type that contained a unit struct as a member. This generated a match arm like:

crate::types::ObjectEncryptionFilter::Sses3(inner) =>
{
    scope_writer.start_el("SSE-S3").finish();
}

inner is never used since there is nothing to serialize for a unit struct, so this caused a warning and CI failure. The change here fixes that warning by prefixing _inner in these cases.

Some other serializer generators also appear to have this bug. Created #4308 to track.

Incompatible lambda-http Version Bug

To unblock CI, this PR also bumps lambda_http to 0.8.4 in aws-smithy-http-server.

Testing

Failed CI tasks are now passing

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[ysaito1001]

Curious, is it possible to use _inner unconditionally and update line 476 (new revision)

serializeMember(member, Ctx.Scope("scope_writer", "_inner"))

??

[landonxjames]

It seems we could, cargo check doesn't complain about it. I assumed it would complain about using a _ prefixed value. But I do think that makes the generated code less idiomatic since it would be making use of _inner. I don't have a strong preference either way if you do

[ysaito1001]

We do use under scored variables across the codegen to handle cases where "this variable may/may not be used" but in a way that doesn't require if else. It'll simplify the codgen code, i.e. can just be back to

val variantName =
    if (member.isTargetUnit()) {
        // ...
    } else {
        "$memberName(_inner)"
    }

While _ is convenient, it hides the fact why the variable is unused in some cases. The code changes in the PR are "honest" about what might happen.

I'm fine with what we have, I was just curious.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• No codegen difference in the Client Test
• No codegen difference in the Server Test
• Server Test Python (ignoring whitespace)
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.