fix(kms): Duplicate KMS startup metadata labels across multiple KMS blocks

[anilvpatel]

Summary:
Fixes incorrect duplicate KMS metadata in Boundary server startup output when multiple KMS blocks of the same provider are configured (for example, Azure Key Vault root, worker-auth, and recovery blocks).

Address Issue: #4236

Description:
During startup, the Boundary controllers and workers write a few log lines which include the names of the keys that are in use. When using more than one block of the same provider (expect AEAD) with different purpose. There is a bug that will only output the name of the last configured key, instead of all names.

For controller config:
run boundary server -config controller.hcl

disable_mlock = true

controller {
   ...
}

listener "tcp" {
  ...
}

listener "tcp" {
  ...
}

kms "azurekeyvault" {
  purpose = "root"
  key_name = "boundary-root"
}

kms "azurekeyvault" {
  purpose = "worker-auth"
  key_name = "boundary-worker"
}

kms "azurekeyvault" {
  purpose = "recovery"
  key_name = "boundary-recovery"
}

Example output from my controller:

Root-Cause:
Boundary passed shared startup info containers (b.InfoKeys and b.Info) directly into configutil.ConfigureWrapper() for every configured KMS block.

For providers like Azure Key Vault, multiple KMS blocks emit the same display labels, such as: Azure Environment, Azure Vault Name, Azure Key Name. go-secure-stdlib/configutil/kms.go

Because b.Info is a map, later KMS blocks overwrote earlier values for the same label, while b.InfoKeys continued appending duplicate keys. This caused startup output to print the same label multiple times, all resolving to the last configured value.

This was a startup info rendering bug only. It did not affect KMS purpose assignment or runtime wrapper usage.

Solution:
Collect KMS metadata per wrapper in temporary local structures, then merge it into b.InfoKeys / b.Info after all KMS blocks have been processed.

When duplicate display labels are detected, qualify them with KMS purpose (and ordinal when the same purpose appears multiple times ex: downstream-worker-auth), so the printed keys remain unique.

For example:
[Root] Azure Key Name
[Worker-Auth] Azure Key Name
[Recovery] Azure Key Name

This keeps startup output accurate without changing runtime KMS behavior.

Scope:
This fix is provider-agnostic and applies to any KMS wrapper type that emits repeated display labels across multiple configured KMS blocks.

Why not fix upstream in configutil?
This was fixed in Boundary rather than configutil because duplicate resolution is a cross-block display concern. configutil only has per-wrapper context, while Boundary has the full set of configured KMS blocks, purposes, and repeated-purpose counts needed to generate stable, unique startup labels.

Tests
Added regression coverage for:

• duplicate KMS metadata labels across different purposes.
• duplicate metadata labels for repeated instances of the same purpose.
• skipping purpose for KMS AEAD type as its already done in upstream.
• preserve all existing info keys