### Bug Description If you provide multiple *craft YAMLs in a single *craft repo, the Fetch Service incorrectly assumes the "metadata.type" of the CRAFT package. For example, see the fetch service metadata for [this bin build](https://launchpad.net/~sd-admin-staging/sd-project/+craft/ubuntu.public.superalpaca-hello-world-2+latest-edge/+build/624/), and grep for `hello-world-2`; the matching sourcecraft repo is [here](https://git.staging.snapcraftcontent.com/ubuntu/public/sourcecraft/superalpaca-hello-world-2/tree/?h=latest_edge). The "metadata.type" for `superalpaca-hello-world-2` is "application/x.canonical.snapcraft" instead of "application/x.canonical.sourcecraft". I think that the Fetch Service should do one (or both) of: 1. Get the "metadata.type" and "metadata.name" from the download (git/CRAFT storage) URL if possible, since the YAML doesn't necessarily have to match these 2. Reject the CRAFT package if we're unable to disambiguate it's type Here's the relevant output from the metadata JSON mentioned above: The `response-inspection` shows: ```json "craft.rockcraft": { "opinion": "Approved", "reason": "rockcraft repository found", "annotations": { "checkout": "07b14bd534988c05bef5f1bdbc4e834614a50ac9" } }, "craft.snapcraft": { "opinion": "Approved", "reason": "snapcraft repository found", "annotations": { "checkout": "07b14bd534988c05bef5f1bdbc4e834614a50ac9" } }, "craft.sourcecraft": { "opinion": "Approved", "reason": "sourcecraft repository found", "annotations": { "checkout": "07b14bd534988c05bef5f1bdbc4e834614a50ac9" } }, ``` but the artefact metadata will just choose one of these ```json "metadata": { "type": "application/x.canonical.snapcraft", "sha1": "f379734635d331dda7f52f01d334e11dd1cdf8cc", "sha256": "7f741bc495d912e02223a73ff74ea6a4926982475fc1cfe689b7dc20788e9eab", "size": 1396, "name": "superalpaca-hello-world-2", "version": "1", "vendor": "", "description": "Single-line elevator pitch for your amazing snap", "author": "", "license": "" }, ``` ### To Reproduce Not 100% sure of the exact steps, but it's something like: 1. Register a `sourcecraft` package 2. In the git repo for the package, create valid `sourcecraft.yaml`, `snapcraft.yaml` and `rockcraft.yaml` and commit them to the registered `sourcecraft` package in the Store 3. The builds for the package will trigger, wait for one of them to succeed 4. Get the Fetch Service Metadata JSON for this build, and it will show that multiple craft inspectors approved the package in the `response-inspection` when pulling in the `sourcecraft` package into the build (like in the Bug Description above) ### Relevant log output _No response_