ci: auto-tag a greater Version on main

[piranout]

PR #1 merged 0.8.1-beta1 to main and CI is green, but the latest GitHub release/tag is still v0.8.0-beta1. release.yml only runs on v* tags (and workflow_dispatch). The merge bumped Version and never pushed a tag, so Release never ran.

What

On push to main only (not PRs):

1. Tag version (.github/workflows/tag-version.yml) reads <Version> from src/Aperture.App/Aperture.App.csproj (falls back to Directory.Build.props if the csproj has none).
2. Compares it to existing v* tags using the same SemVer rules as the in-app updater (UpdateVersion — prerelease suffixes matter). Shared decision logic is ReleaseTag.cs; the tag job runs a thin scripts/DecideReleaseTag helper that compiles those same sources.
3. If the landed version is greater and v{version} does not exist, it creates and pushes that tag (never force-pushes). Equal or lower versions are left untagged.
4. A GITHUB_TOKEN tag push does not start other workflows, so the tag job then calls the existing release.yml (workflow_call, secrets: inherit). Signing/publish is unchanged and not duplicated.

docs/GITHUB-SETUP.md “Cutting a release” is now: bump Version + CHANGELOG on main; the tag is automatic. Manual git tag / workflow_dispatch stay as fallbacks.

Signing vs Markdown Midget (verified, no secret values)

Diffed Aperture .github/workflows/release.yml signing steps against published Markdown Midget release.yml. Identity still matches. Aperture did not drift. Signing YAML on this branch is identical to main (this PR only added workflow_call so the tag job can invoke it).

	Aperture	Markdown Midget
Secrets	AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_CLIENT_SECRET	same names
Account	func-az-artifact-signing	same
Profile	funcular-labs-public-trust	same
Endpoint	https://cus.codesigning.azure.net/	same
Tool	azuretrustedsigntool sign + Windows SDK signtool.exe	same
Description	Aperture Image Viewer	Markdown Midget (the only intended product difference)
Fail-fast if secrets missing	kept (Aperture-only; missing secrets used to hang ~20 min)	Midget’s published YAML does not have this step

No new cert, key, or SP. The auto-tag job does not sign and does not bypass Release.

Org secret repository-allowlists cannot be read from this repo. The YAML is correct. The last published asset Aperture-v0.8.0-beta1-win-x64.exe was uploaded by github-actions[bot]; that Release run’s Check signing secrets are present, Sign the exe (Azure Trusted Signing), and Verify Authenticode signature steps all succeeded — so the allowlist was working then.

First ship of 0.8.1-beta1

Do not tag from this PR. After this merges, Tag version runs on that main push, sees 0.8.1-beta1 > v0.8.0-beta1, and should create v0.8.1-beta1 and invoke the same signed Release job.

How to test

1. CI on this PR: dotnet test includes the new ReleaseTagTests; the extra “Release-tag helper” step must print should_tag=true / tag=v0.8.1-beta1 against a fake v0.8.0-beta1 list.
2. After merge: Actions → Tag version should push v0.8.1-beta1 and start Release (signed exe + prerelease).
3. A later main push that does not raise Version must not create or move a tag.

Permissions

• Tag job: contents: write only (create/push the tag).
• The reusable Release job keeps contents: write so it can still create the GitHub release (same as today’s tag-triggered run).
• No secrets in the tree; repo visibility unchanged.