RFC: Add `service-mesh` skill to aws-dev-toolkit

[dshamanthreddy]

Summary

Add a standalone service-mesh skill to aws-dev-toolkit covering service mesh on
EKS — Istio (sidecar + ambient), mTLS, L7 traffic management, and how it relates to
the AWS Gateway API and App Mesh's deprecation.

Motivation

The eks skill covers cluster lifecycle but nothing on east-west traffic or service
mesh. Questions about mTLS between services, canary/blue-green traffic shifting, or
Istio on EKS have no targeted skill today.

Proposed Solution

• New folder: solution-architecture/plugins/aws-dev-toolkit/skills/service-mesh/
• Single flat SKILL.md in dev-toolkit style (process → defaults → CLI → output table
  → related skills → anti-patterns). No references/ folder.
• Trigger: service mesh, mTLS, traffic shifting, east-west traffic, Istio on EKS.
• Covers: when a mesh is/isn't justified, install (sidecar vs ambient), mTLS, traffic
  management, observability (Kiali), cost, alternatives (Gateway API, Cilium).
• Cross-link with eks, networking, observability.

Alternatives Considered

• Fold into eks — rejected: doubles its size and dilutes its trigger.
• Name it istio — rejected: no skill is named after an OSS tool; concept names
  (networking, observability) are the convention.

Open Questions

• Name service-mesh vs eks-service-mesh?
• Istio-only or include Cilium/Linkerd contrast?

Drawbacks

• Adds to skill count; mesh tooling moves fast and will need periodic refresh.

[igkins]

for naming, I'd do eks-service-mesh. I think the skill should def do istio, and cilium, but have the skill ask the user. Be sure to mention cilium doesn't work with auto-mode