Say why no_tags fired when the repo has tags but none parse

[lesnik512]

This was generated by AI during triage.

When a repo has tags but none of them is a latest-tag candidate, semvertag reports no_tags and exits 0. The reason it gives is the same one a tagless repo gets: create an initial tag such as 0.1.0. A repo tagged V1.2.0, release-1.2.0 or 0.9.0rc1 (PEP 440) therefore sees a green CI run that never tags and a hint that suggests it has no tags at all, with nothing pointing at the tag format.

#58 (PR #93) made lowercase-v tags readable, which removes the most common case. The remaining forms are still silently skipped by design (ADR-0003), so the diagnostic gap is what's left of the original complaint.

The change: when tag selection finds no candidate but the forge listed at least one tag, the no_tags reason (JSON wire text and the Rich message) says so, e.g. "found N tags, none SemVer-form (1.2.0 or v1.2.0)", possibly naming one or two examples.

Things the change has to settle:

• Where the count comes from. NoTags currently carries only commit. Adding a field to the outcome, or to RunResult, means re-running the field audit pinned by test_no_run_result_field_carries_user_supplied_text (test: pin RunResult's fields so a new one forces a redaction audit #92): tag names come from the repo, so quoting them in the JSON envelope is user-supplied text that JsonOutput.emit does not redact.
• Whether the status stays no_tags. The status tokens are a frozen wire contract (schema_version "1.0"), so the reason text is the place to say it, not a new status.

Revisit trigger: none; actionable once someone decides how much of the tag list to surface.

[lesnik512]

This was generated by AI during triage.

Triage Notes

Grilled with the maintainer; being implemented now.

Decisions:

• Count only, no tag names. The no_tags reason says how many tags the repo has when none is SemVer-form, and never quotes them. Tag names are repo-supplied text, and quoting them in reason would need per-field redaction in JsonOutput.emit and break the audit pinned in test: pin RunResult's fields so a new one forces a redaction audit #92. A count keeps reason semvertag-controlled.
• Status stays no_tags, exit stays 0. Failing CI on upgrade for repos whose only tags are floating majors (v1) or PEP 440 would be worse than the silent green run.
• The count lives on the internal NoTags outcome (defaulting to 0), not on RunResult. The wire fields and schema_version don't change.
• Wording. With zero tags the message is unchanged. With N > 0: "None of the repo's N tag(s) is SemVer-form (1.2.0 or v1.2.0); create an initial tag such as 0.1.0 (or v0.1.0 for v-prefixed tags) on a default-branch commit." The Rich message follows the same pattern.
• Docs. A Troubleshooting entry in both provider guides covering ignored forms (V1.2.0, release-1.2.0, 0.9.0rc1, floating v1). No ADR, no glossary change.