fix(manager): prevent orphaned alias keys from create/destroy race in containerMap

[iiiFonryn]

Refer to #3924.

createContainer and destroyContainer operate on a group of keys (the canonical namespacedName plus all aliases) without a shared lock, relying only on sync.Map's per-key atomicity. A create/destroy interleaving could leave an alias key with no corresponding canonical record. Such an orphan is never revisited by getContainersDiff (which keys off the canonical record via cont.info.Name == name.Name), so it leaks permanently.

Store the canonical namespacedName last in createContainer (it is deleted first in destroyContainer). Under this ordering any leaked alias must be accompanied by a leaked canonical name, which global housekeeping detects and reclaims together with its aliases. This does not remove the race itself; it guarantees the leak is always self-healable.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.