[feature]: `tapd --version`: make non-release builds unambiguous

[ffranr]

Context

A user reported:

tapd --version
tapd version 0.7.0-alpha commit=v0.7.0-143-g46bebd3a

They were running a main build. The output was misinterpreted as “on 0.7.0”.

Problem

Branch builds can look like release builds. This causes support/debug confusion.

Goals

• Output remains one line.
• Preserve as much backwards-compatibility as possible for release builds.
• Make non-release builds impossible to mistake for a release.

Proposal

1. For tagged release builds, retain the existing prefix tapd version vX.Y.Z commit=... and append new structured fields at the end.
2. For non-release builds, change the version token to an explicit non-release marker (e.g. UNRELEASED) and append the same structured fields.

Example outputs

Release build:

tapd version v0.7.0 commit=46bebd3a release_build=true ref=refs/tags/v0.7.0 describe=v0.7.0 dirty=false

Main branch build:

tapd version UNRELEASED commit=46bebd3a release_build=false ref=refs/heads/main describe=v0.7.0-143-g46bebd3a dirty=false

Dirty local build:

tapd version UNRELEASED commit=46bebd3a release_build=false ref=local describe=v0.7.0-143-g46bebd3a-dirty dirty=true

Behavior rules

• release_build=true only for exact release tag builds (or an explicit build flag set by the release pipeline).
• If release_build=false, the “version” token must be a non-release marker (no semver, no 0.7.0-alpha).
• Append-only fields at end: release_build=... ref=... describe=... dirty=... to minimize parser breakage.
• ref/describe/dirty should be set via ldflags in CI when possible; fallback to unknown/local.

Acceptance criteria

• Release builds remain parse-compatible with the current tapd version vX.Y.Z commit=... prefix.
• Non-release builds cannot be mistaken for a release from a quick glance.
• Output is one line.
• Tests cover release vs non-release vs dirty and missing metadata fallbacks.