fix: eliminate data races in fake IAM and SSM API test doubles

[Archong-Liu]

Related to #7969

Description

While looking into #7969 (data races surfaced when running tests with the race detector), I found three concrete, reproducible data races in the fake AWS API test doubles under pkg/fake. These are test-harness-only bugs (the production code paths deserialize a fresh AWS response per call and never alias state), but they can cause flaky failures and even hard panics when tests run concurrently under -race.

1. IAMAPI.Reset() doesn't hold the lock (pkg/fake/iamapi.go)

IAMAPI embeds sync.Mutex, and every other method (GetInstanceProfile, CreateInstanceProfile, DeleteInstanceProfile, TagInstanceProfile, AddRoleToInstanceProfile, RemoveRoleFromInstanceProfile, ListInstanceProfiles) takes s.Lock() before touching s.InstanceProfiles/s.Roles. Reset() alone reassigned both maps with no lock, racing against any concurrent locked method. Fixed by acquiring the lock in Reset() like every other method.

2. Pointer escape from IAMAPI getters (pkg/fake/iamapi.go)

GetInstanceProfile and CreateInstanceProfile returned the same *iamtypes.InstanceProfile pointer stored in the internal map. The instanceprofile provider caches that pointer (instanceProfileCache.SetDefault(...)) and then mutates it directly (instanceProfile.Roles = []iamtypes.Role{...}) outside the fake's lock, so the mutex protected nothing once the pointer escaped. A real AWS API returns a freshly deserialized, independent object per response, so these methods now return a copy (shallow struct copy plus cloned Roles/Tags slices). ListInstanceProfiles had the same slice-aliasing issue (it copied the struct by value but shared the Roles/Tags backing arrays) and now returns copies too.

3. SSMAPI has no mutex (pkg/fake/ssmapi.go)

SSMAPI had no synchronization at all. GetParameter did an unsynchronized check-then-act on the shared defaultParameters map (read, check, write) while Reset() reassigned it. Since Go maps are not safe for concurrent read/write, this can trigger a fatal error: concurrent map read and map write panic, not just wrong data. Note GetParameter used a value receiver, so even adding a field mutex wouldn't have helped — a value receiver copies the mutex. Fixed by adding an embedded sync.Mutex, switching GetParameter to a pointer receiver, and locking in both GetParameter and Reset().

I also checked the other fakes in pkg/fake/*.go for the same two anti-patterns. The rest are already safe (ec2api.go uses sync.Map; eksapi.go/sqsapi.go/arczonalshiftapi.go use the atomic helpers in atomic.go/types.go; pricingapi.go builds fresh maps per call), so this change is intentionally scoped to just iamapi.go and ssmapi.go.

Note this does not fully resolve #7969 — a separate integration/E2E-test race described in that issue is being investigated independently and is out of scope here. This PR only addresses the fake-client races above.

How was this change tested?

• Added -race regression tests in pkg/fake (iamapi_test.go, ssmapi_test.go): the pointer-escape tests fail on the unfixed code (mutation leaks into internal state), and the concurrency tests report WARNING: DATA RACE on the unfixed code for both IAMAPI.Reset() and SSMAPI.GetParameter()/Reset(). All pass after the fix.
• go test -race ./pkg/fake/... — pass (repeated).
• go test -race ./pkg/providers/instanceprofile/... and ./pkg/providers/amifamily/... (heavy consumers of these fakes) — pass under -race.
• gofmt -l, go vet ./..., and go build ./... — clean.

Does this change impact docs?

• Yes, PR includes docs updates
• Yes, issue opened: #
• No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.