Fix concurrent map iteration and write panic in AppRefTracker

[somaz94]

What this PR does / why we need it:

AppRefTracker.AppsForRef and RefsForApp returned the internal map by
reference. Callers such as SecretHandler.enqueueAppsForUpdate and
ConfigMapHandler.enqueueAppsForUpdate iterate that map after the tracker lock
is released, so a concurrent ReconcileRefs / RemoveAppFromAllRefs writing the
same map crashes kapp-controller with fatal error: concurrent map iteration and map write. This reproduces on large clusters with thousands of
namespaces/secrets under continuous reconciliation.

Both methods now return a shallow copy of the RefKey set while holding the lock,
so callers iterate a private map and never race the writers. The two callers
only iterate the result (read-only), so returning a copy is behavior-preserving.

Which issue(s) this PR fixes:

Fixes #1843

Does this PR introduce a user-facing change?

Fix panic ("concurrent map iteration and map write") in AppRefTracker that could
crash kapp-controller on large clusters under high reconciliation concurrency.

Additional Notes for your reviewer:

Added two regression tests in pkg/reftracker/ref_tracker_race_test.go
(concurrent read+iterate against a concurrent writer, for both AppsForRef and
RefsForApp). Before the fix they crash with the reported fatal error; after it
they pass, including under -race.

Validation run locally:

• go test ./pkg/reftracker/... -race passes (existing + new tests)
• gofmt / go vet clean

Review Checklist:

• Follows the developer guidelines
• Relevant tests are added or updated
• Relevant docs in this repo added or updated (n/a, internal bug fix)
• Relevant carvel.dev docs added or updated (n/a)
• Code is at least as readable and maintainable as it was before this change