Metadata identifiers are chosen incorrectly

`AsyncMetadataKey.identifiers` is documented twice as "sorted with the most-preferred first," and the `.creator` key in particular is carefully ordered and visually grouped into preference tiers. But `AsyncMetadata.performSearch` does:

```swift
assetMetadata.first(where: { key.identifiers.contains($0.identifier) })
```

That walks **the asset's** metadata array and returns the first item matching *any* identifier. The key's ordering is never consulted. Whichever identifier the file happens to list first wins.

This explains the `id3/TPE2` (band / album-artist) result you saw during the #4 debugging session rather than `commonIdentifierArtist`, which sits higher in the preference list. Practical consequence: `.creator` can surface the publisher, conductor, or lyricist as the artist on files that carry those tags earlier in their metadata.

An order-honoring search would be roughly:

```swift
key.identifiers.lazy
.compactMap { wanted in assetMetadata.first { wanted == $0.identifier } }
.first
```

Start at AsyncMetadata.performSearch and compare its lookup behavior with the ordering documented for AsyncMetadataKey.identifiers, especially the .creator key. Confirm that the preferred identifier wins when asset metadata is arranged differently, and that commonIdentifierArtist is selected ahead of lower-preference identifiers.

Written by the indexing model from the issue text.