fix(labels): fix broken label file parsing in archive upload modal

[tthvo]

Welcome to Cryostat! 👋

Before contributing, make sure you have:

• Read the contributing guidelines
• Linked a relevant issue which this PR resolves
• Linked any other relevant issues, PR's, or documentation, if any
• Resolved all conflicts, if any
• Rebased your branch PR on top of the latest upstream main branch
• Attached at least one of the following labels to the PR: [chore, ci, docs, feat, fix, test]
• Signed all commits using a GPG signature

To recreate commits with GPG signature git fetch upstream && git rebase --force --gpg-sign upstream/main

---

Fixes #1322

Description of the change:

Fixed the incorrect label parsing utility. The labels should be rendered correctly now.

Motivation for the change:

See #1322

[tthvo]

Hmm, I think it comes down to the expected structure of the metadata file. I guess we should have an example in the help icon.

Are we using the previous format { "labels": { "my-key": "my-value" } } or { "labels": [ { "key": "my-key", "value": "my-value" } ] } (same as one downloaded in Recording view)?

[andrewazores]

Hmm, I think it comes down to the expected structure of the metadata file. I guess we should have an example in the help icon.

I don't think it's really necessary for the help icon to provide an example. The expected purpose here is for the user to just re-upload metadata files they have previously downloaded, so if they need to know the format they can inspect the file directly. Otherwise, it's really just an implementation detail.

Are we using the previous format { "labels": { "my-key": "my-value" } } or { "labels": [ { "key": "my-key", "value": "my-value" } ] } (same as one downloaded in Recording view)?

{ "key": "my-key", "value": "my-value" } should be the new format everywhere, I think. Easier to manage it when we are consistent in every case. A lack of consistency, or checking for consistency, is what gave rise to this bug after all.