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

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.