Add Smithy metadata translation to codegen

[Fred1155]

Motivation and Context

This adds the smithy translator for service-level metadata, such as service and class names, package names, API version,
protocol, endpoint prefix, signing name, auth, and the doc identifiers. This is the Smithy counterpart to AddMetadata.

C2J keeps all of this in one flat metadata block. Smithy spreads it across traits, and for some fields stores nothing at all . The value is implied by which trait is present, or sits inside another trait. Six fields need that handling; the rest are a trait read replacing a JSON field read.

Modifications

File	Role	C2J counterpart
smithy/AddSmithyMetadata.java	service traits → Metadata	AddMetadata
smithy/AddSmithyMetadataTest.java (13)	coverage	—

Nothing wired into the codegen or IM builder yet.

Metadata field	C2J source	Smithy source
package, client, builder, base names	naming strategy	same
apiVersion	metadata.apiVersion	ServiceShape.getVersion()
documentation	serviceModel.getDocumentation()	@documentation
serviceFullName	metadata.serviceFullName	@title
serviceId	metadata.serviceId	@aws.api#service sdkId
endpointPrefix	metadata.endpointPrefix	@aws.api#service endpointPrefix
signingName	metadata.signingName	naming strategy (@sigv4.name)
protocol	resolveProtocol(ServiceMetadata)	resolveProtocol(ServiceIndex, service)
jsonVersion	metadata.jsonVersion, else 1.1	awsJson trait version, else 1.1
authType	metadata.signatureVersion	@sigv4 present → V4
auth	metadata.auth	@auth values, else applied auth trait
awsQueryCompatible	metadata.awsQueryCompatible	trait present → empty map
uid	metadata.uid	ServiceTrait.resolveDocId(service)
supportsH2	protocolSettings.containsKey("h2")	h2 in protocol trait lists
serviceAbbreviation	metadata.serviceAbbreviation	no equivalent

This class takes the naming strategy as a parameter instead of building one, since the caller already has it.

Divergences

Field	What's different	Why	Impact
jsonVersion	read from the trait name, not a field	Smithy has no jsonVersion field; @awsJson1_0 vs @awsJson1_1 carries it. rest-json and rpcv2Cbor have no version and take C2J's 1.1 default	none, same value
auth	falls back to the applied auth trait when @auth is absent	C2J stores effective auth. EC2 has @sigv4 and no @auth, so reading only @auth would leave it empty	none, fallback restores parity
awsQueryCompatible	trait presence → empty map	Smithy uses an annotation trait, which holds no value. C2J's map is always empty anyway — it's a marker	none
uid	from the docId member	Smithy's field for doc links. C2J has no uid equivalent	matches C2J on 424/425 models; appmesh differs
supportsH2	from the protocol trait's http / eventStreamHttp lists	C2J derives it from protocolSettings, which Smithy doesn't have	matches C2J on 425/426 models; bedrock-agent-runtime differs
serviceAbbreviation	left null	No Smithy equivalent. The trait declares no abbreviation member, and sdkId is an identifier, not a display name (matches C2J 24% of the time vs 68% for the existing @title fallback)	javadoc wording only — getDescriptiveServiceName() falls back to the full service name

Everything else AddMetadata populates is populated here; serviceAbbreviation is the only field left null.

Testing

AddSmithyMetadataTest builds small inline Smithy models and asserts one field each

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license

[S-Saranya1]

nit: Similar to jsonVersion and supportsH2, should we add tests for auth as well? The fallback logic has a few distinct paths that aren't directly covered.