Decide whether the LF container tag idiom becomes an action

[ModeSevenIndustrialSolutions]

Problem

docs/BRIEF.md section 6 item 3 listed docker-tags-action as a maybe, to be decided during implementation: "LF tag-idiom resolver; decide whether in-workflow bash suffices".

Implementation answered it implicitly by keeping the logic inline. merge.yaml spends 75 lines in "Publish snapshot/staging tags" computing and pushing the Linux Foundation tag set, plus 13 lines resolving the version from version.properties.

Re-measured 2026-09-17 against main at v0.6.1: still 75 lines, unchanged since filing.

The tag idiom is a genuine domain rule, not glue:

• X.Y.Z-SNAPSHOT-latest
• X.Y-STAGING-latest
• X.Y.Z-<timestamp>Z

It is also the piece most likely to be an external interface, since downstream tooling may parse those tags — the open question in #31. Rules that other systems parse deserve to live somewhere testable, with cases pinning each form.

What changed since filing

The tag computation now runs on every pull request under the merge lane's dry_run self-test (#84). That does not decide this issue, but it changes the cost of both outcomes:

• If the decision is "keep inline": the logic is no longer wholly untested. The derivation executes in CI, so the worst case — a domain rule with no coverage at all — no longer applies. That weakens the argument for extraction.
• If the decision is "extract": the self-test gives a behavioural baseline to extract against, so the action can be proven equivalent rather than merely plausible.

Still blocked on #31

The decision itself has not moved, and cannot until #31 resolves:

• Extract if the tag set is an interface (see Confirm whether the timestamped snapshot tag format is an interface #31) or once a second lane needs it.
• Keep inline if it stays a single-call-site detail, and close this issue recording that decision so the brief's open item does not stay ambiguous.

Note that the second extraction trigger — "a second lane needs it" — remains unmet. build-test-release.yaml derives its own tags from the release tag rather than from version.properties, and deliberately so; the two lanes implement different idioms, not one idiom twice.

If extracted, cover: release versus snapshot input versions, timestamp formatting and timezone, the latest variants, and malformed version.properties.

Notes

lfreleng-actions/build-metadata-action already reads version.properties and is used here, so an extraction should extend the existing seam rather than add a parallel one.