baseline: use mainline remote-tracking ref instead of HEAD

[ftabba]

The mainline fallback candidate in baseline resolution was LocalRef("HEAD"), which resolves to whatever the local repo has checked out. Nothing in Sashiko advances the local HEAD after fetching: GitSyncWorker updates remote-tracking refs (origin/master) but never the local checkout. So HEAD drifts behind origin/master indefinitely.

Additionally, ensure_remote fetches with --no-tags, so annotated tag objects are never available locally. b4 can emit annotated tag object SHAs as the base-commit header (the tag object rather than the commit it points to), and these are not fetchable by SHA either.

Trigger: Mark Brown's KVM/arm64 SME v11 series included base-commit: 4c45e14df2f4e77982ad70d6d8e3fe750edd4c37, which is the annotated tag object for v7.2-rc2. Sashiko could not resolve it for two reasons: the tag object was never fetched (--no-tags), and the fallback to HEAD resolved to a stale commit well behind origin/master. The series applies cleanly to v7.2-rc2, but Sashiko failed to apply it and did not produce a review.

Fixes:

1. Use mainline remote-tracking ref instead of HEAD. Store the identified mainline remote (Linus tree or origin) in BaselineRegistry and emit it as a RemoteTarget instead of LocalRef("HEAD"). This causes ensure_remote to fetch the remote if stale, and resolves the ref to the remote-tracking branch (e.g. origin/master) rather than the local checkout. Falls back to LocalRef("HEAD") when no mainline remote can be identified.

2. Fetch tags when base-commit SHA is unresolvable. When the direct git fetch <sha> recovery fails to resolve a Commit baseline, fetch tags from the mainline remote (git fetch <remote> --tags) and retry. This handles the b4 case where base-commit is a tag object SHA. Tags are fetched from the mainline remote that BaselineRegistry already identifies, so it does not assume the remote is named origin, and it keeps the tag namespace clean rather than pulling every subsystem tree's tags. Only fires in the already-failing recovery path.

3. Fetch the missing base commit from the mainline remote. The pre-existing direct base-commit recovery fetched from a hardcoded origin. The mainline remote is not always named origin (it may be Linus's tree under a different name), in which case the fetch targeted the wrong remote and silently failed. Use the identified mainline remote, matching the tag-fetch recovery.

[broonie]

That's not a local object FWIW, that's Linus' tag for v7.2-rc2 so it's possible local reproduction might find the tag happily if you've pulled tags - probably it's worth Sashiko pulling tags from at least Linus' tree since this behaviour is coming from b4. Possibly also -next since people often use it as a base for cross-subsystem serieses.

[ftabba]

That's not a local object FWIW, that's Linus' tag for v7.2-rc2 so it's possible local reproduction might find the tag happily if you've pulled tags - probably it's worth Sashiko pulling tags from at least Linus' tree since this behaviour is coming from b4. Possibly also -next since people often use it as a base for cross-subsystem serieses.

Thanks for the correction. The base-commit is indeed the annotated tag object for v7.2-rc2, not a local-only SHA. Sashiko was fetching with --no-tags everywhere, so tag objects were never available locally, and the direct git fetch origin recovery also fails because git servers don't expose tag objects for fetch by SHA.

I've added a second commit that fetches tags from origin when the direct SHA fetch fails to resolve. This only fires in the already-failing recovery path.

[ftabba]

Mark resent it, unfortunately, HEAD wasn't advanced (same bug the first commit this PR fixes), so it didn't apply:

https://sashiko.dev/#/patchset/20260709-kvm-arm64-sme-v12-0-d0301d79ef58%40kernel.org