Prefer Soto for AWS integrations in Swift guidance

[gaelic-ghost]

Goal

Update Socket’s Swift/server-side Swift guidance so Soto is the default AWS client stack for new Swift services.

Why

For our server-side Swift work, Soto is the preferred operational and ergonomic fit. TokenBrokerCloud already uses SotoCore, SotoDynamoDB, and SotoSSM; new guidance should lead agents toward that stack instead of defaulting to the official AWS SDK for Swift.

Scope

• Find guidance and skills that recommend or select an AWS SDK for Swift services.
• Make Soto the default recommendation for new AWS integrations.
• Keep the official AWS SDK for Swift as an explicit alternative when a required service/API, compatibility constraint, or repository contract makes Soto unsuitable.
• Require a short documented reason when deviating from Soto.
• Use fetchable, pinned SwiftPM dependencies; do not introduce machine-local package paths.
• Add or update workflow/evaluation coverage so generated server-side Swift examples choose Soto by default.
• Preserve existing repository-specific SDK choices unless a migration is separately requested.

Acceptance criteria

• Relevant guidance consistently identifies Soto as the default.
• The exception rule for choosing the official AWS SDK is concrete and testable.
• At least one fixture/eval or documentation example demonstrates a Soto-based AWS client lifecycle suitable for a long-running service or Lambda warm invocations.