External plugin quality gates report `infra_error` for valid tag refs (`git fetch origin <tag>` doesn't create a local ref)

[tlmii]

Summary

The external-plugin quality-gate harness (eng/external-plugin-quality-gates.mjs) fails the version match and canvas structure gates with an infra_error whenever a submission's source.ref is a tag name (e.g. v1.1.247), even though the tag is valid and resolves correctly on the source repo. The gate reports:

- v1.1.247: Unable to read "plugins/upgrade-agent/.github/plugin/plugin.json" at "v1.1.247": fatal: invalid object name 'v1.1.247'.

This is a harness bug, not a problem with the submitted data. Both affected gates then roll up to overall: infra_error, forcing unnecessary maintainer follow-up on otherwise-valid submissions.

Root cause

runVersionMatchGate and runCanvasStructureGate iterate over both locators in source (ref and sha). For any non-primary locator they call fetchLocatorIntoRepo followed by git show <locator>:<path>:

// fetchLocatorIntoRepo (eng/external-plugin-quality-gates.mjs:334)
git fetch --depth=1 origin v1.1.247        // exit 0 — but only updates FETCH_HEAD

// readPluginManifestAtLocator (:355)
git show v1.1.247:plugins/.../plugin.json  // fatal: invalid object name 'v1.1.247'

The problem: git fetch origin <tagname> updates only FETCH_HEAD; it does not create a local refs/tags/<tagname>. The fetch reports success (exit 0), but the subsequent git show <tag>:… has no ref to resolve and dies with fatal: invalid object name.

The SHA locator passes because a raw SHA is a direct object name — once the objects are in the local object DB (they are, via FETCH_HEAD), git show <sha>:… resolves without needing any ref. That asymmetry is exactly what the reports show.

Reproduction

git init -q repo && cd repo
git remote add origin https://github.com/microsoft/upgrade-agent-plugins.git
git fetch --depth=1 origin v1.1.247        # exit 0
git show-ref                                # EMPTY — no local ref created
git show v1.1.247:plugins/upgrade-agent/plugin.json
# fatal: invalid object name 'v1.1.247'

Impact / scope

Not unique to one submission — any external plugin that provides a tag ref alongside a sha hits this. Confirmed on at least:

• PR #2394 (upgrade-agent, ref v1.1.247)
• Issue #2353 (copilot-rulefoundry, ref v1.0.0) — identical invalid object name 'v1.0.0' symptom

Suggested fix (harness side)

Either of these makes git show <tag>:… resolve (both verified working against the real remote):

• A — fetch the tag into a local ref: git fetch --depth=1 origin tag <name> creates refs/tags/<name>, so git show <name>:… works.
• B — resolve via FETCH_HEAD: after the plain fetch, read with git show FETCH_HEAD:… instead of git show <locator>:…. (Note: FETCH_HEAD is overwritten by each subsequent fetch, so the read must happen before the next locator is fetched.)

Note this is a distinct bug from #1783 (fully-qualified refs/tags/... refs breaking git clone --branch at install time); this one is in the quality-gate harness's git show path.

Acceptance criteria

• A submission whose source.ref is a tag name (with or without an accompanying sha) passes the version-match and canvas-structure gates when the referenced content is valid.
• Regression coverage added in eng/external-plugin-quality-gates.test.mjs for the tag-locator path.